<HTML>
<HEAD>
<title> rel5.0 </title>
</HEAD>
<BODY  bgcolor="#ffffff"  text="#000000">

<center>
<h1> rel5.0 </h1>
</center>

<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa10907; 31 Jan 95 20:23 GMT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id ab09855; 31 Jan 95 19:13 GMT
Received: from worm.arl.mil by WALRUS.ARL.MIL id aa09831; 31 Jan 95 19:11 GMT
Date:     Tue, 31 Jan 95 19:05:30 GMT
From:     Lisa Garriques (SURVICE|mermagen) &lt;lisag@ARL.MIL&gt;
To:       cad@ARL.MIL
Subject:  SURVIAC BRL-CAD Training
Message-ID:  &lt;9501311905.aa28008@worm.arl.mil&gt;

<p>
     /*******************************************************************/
     /* REMINDER * REMINDER * REMINDER * REMINDER * REMINDER * REMINDER */
     /*******************************************************************/

<p>
SURVIAC will be offering its two introductory BRL-CAD training courses
according to the following schedule:

<p>
             BRL-CAD COURSE                   |             DATES
----------------------------------------------|------------------------------
101 Construction, Interrogation, and Imaging  | 22-23 Feb 95    17-18 May 95
102 Geometry Conversion                       |    24 Feb 95       19 May 95

<p>
Advanced courses are available upon request to address in-depth BRL-CAD
topics and specific student requirements.  For additional information,
contact Lisa Garriques at the SURVIAC Aberdeen Satellite Office via the
routes provided below.

<p>
***************************************************************************
*           __        __      ___  __   __     __   __   __               *
*          |__  |  | |_/ \  /  |  |__| |      |__| |__  |  |              *
*           __| |__| | \  \/  _|_ |  | |__    |  |  __| |__|              *
*                                                                         *
***************************************************************************
* The DoD-sponsored Survivability/Vulnerability Information Analysis      *
* Center (SURVIAC) Aberdeen Satellite Office (ASO), located adjacent to   *
* the Aberdeen Proving Ground in Maryland, provides full service          *
* distribution and support for the BRL-CAD model for a $500 fee.  This    *
* includes the initial distribution of the model and documentation,       *
* installation support, maintenance release updates, technical support,   *
* and future activities information.  Additionally, we sponsor an annual  *
* BRL-CAD User's Group Meeting each fall.  Training courses are also      *
* offered periodically each year.                                         *
*                                                                         *
* SURVIAC provides the DoD community with a one-stop resource for all     *
* aspects of nonnuclear survivability, lethality, and mission             *
* effectiveness, which includes dissemination of information and models   *
* to support this community.                                              *
***************************************************************************
* SURVIAC Aberdeen Satellite Office      Phone:  (410) 273-7794           *
* 1003 Old Philadelphia Road             FAX:    (410) 272-6763           *
* Suite 103                              E-mail:  cad-dist@arl.mil        *
* Aberdeen, MD  21001-4011                        lisag@arl.mil           *
***************************************************************************
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa20031; 1 Feb 95 3:27 GMT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa16065; 1 Feb 95 2:59 GMT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa16062; 1 Feb 95 2:57 GMT
Date:     Wed, 1 Feb 95 2:52:16 GMT
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       CAD@ARL.MIL
cc:       STOVALL@eglin.af.mil
Subject:  "BURST" now available with BRL-CAD 4.4
Message-ID:  &lt;9502010252.aa19129@wolf.arl.mil&gt;

<p>

<p>
To our Air Force and Navy users:  good news! ARL has been authorized to
directly distribute the "BURST" code (see attachment).  BURST provides
FASTGEN3 and FASTGEN4 ray files from BRL-CAD geometry files.

<p>
BURST will be a standard item in the next full BRL-CAD distribution.  If
you require a version of BURST for use with BRL-CAD Release 4.4, please
drop a line to John Anderson &lt;jra@arl.mil&gt; or FAX 410-278-5058 to alert
him to your need.  I imagine that as an interim measure we will provide
a supplemental encrypted TAR file on the anonymous FTP server as our
primary means of making this software available to the community.

<p>
Please join me in saying a warm "Thank-You" to Mr. Stovall!

<p>
	Best,
	 -Mike

<p>
----- Forwarded message # 1:

<p>
Date: Fri, 27 Jan 1995 15:56:57 -0600 (CST)
From: "STOVALL, ROBERT L." &lt;STOVALL@eglin.af.mil&gt;
Subject: Burst Release Authority

<p>
Dr Deitz and Mr Anderson,

<p>
	Recently, the CHICKEN LITTLE program office has received
another request for the "burst" code.  We have reassessed our
previous need to maintain control over this code and have
determined that it would be in the best interests of the
DOD Vulnerability/Lethality community to release control of
this code to you for inclusion and distribution with the
BRL-CAD package if you see fit.  If you have any questions,
please contact me at DSN 872-9243 [(904) 882-9243) or my technical
representative, Mr. Bud Bruenning, (904) 729-6497.

<p>
Mr. Robert Stovall
Joint Munitions T&E Program Office

<p>
----- End of forwarded messages
<hr>
<hr>
Received: from worm.arl.mil by wolf.arl.mil id aa01625; 1 Feb 95 13:31 GMT
From: "Gary S. Moss" &lt;moss@arl.mil&gt;
Message-Id: &lt;9502010828.ZM4599@arl.mil&gt;
Date: Wed, 1 Feb 1995 08:28:04 -0500
In-Reply-To: Mike Muuss &lt;mike@ARL.MIL&gt;
        ""BURST" now available with BRL-CAD 4.4" (Feb  1,  2:52am)
References: &lt;9502010252.aa19129@wolf.arl.mil&gt;
X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail)
To: Mike Muuss &lt;mike@arl.mil&gt;, CAD@arl.mil
Subject: Re: "BURST" now available with BRL-CAD 4.4
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0
Sender: moss@arl.mil

<p>
On Feb 1,  2:52am, Mike Muuss wrote:
&gt; Subject: "BURST" now available with BRL-CAD 4.4
&gt;
&gt; To our Air Force and Navy users:  good news! ARL has been authorized to
&gt; directly distribute the "BURST" code (see attachment).  BURST provides
&gt; FASTGEN3 and FASTGEN4 ray files from BRL-CAD geometry files.
&gt;
&gt; BURST will be a standard item in the next full BRL-CAD distribution.  If
&gt; you require a veOn Feb 1,  2:52am, Mike Muuss wrote:
&gt; Subject: "BURST" now available with BRL-CAD 4.4
&gt;
&gt; To our Air Force and Navy users:  good news! ARL has been authorized to
&gt; directly distribute the "BURST" code (see attachment).  BURST provides
&gt; FASTGEN3 and FASTGEN4 ray files from BRL-CAD geometry files.

<p>
Mike,
	This is perhaps an oversimplification. ;-)  BURST provides Shotline
files and Burst Point Library files which contain the same information used
by the PDAM code and previously provided by PGEN from FASTGEN descriptions.
In any case, the format of BURST's output files are syntactically different,
so a conversion is necessary to read them from codes like PDAM.  The file
burst/burst.format describes the file formats so that it is straightforward
to write a Fortran or C routine to read them.  They are much easier to for
a human to read than the compressed Fortran format previously used.

<p>
-Gary

<p>

<p>
--

<p>
"Sometimes nothing fails like success."
- W. Wayt Gibbs [Scientific American, Sep 1994, "Software's Chronic Crisis"]
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa21886; 15 Feb 95 20:20 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa09216; 15 Feb 95 19:23 EST
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa09209; 15 Feb 95 19:17 EST
Date:     Wed, 15 Feb 95 19:10:47 EST
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       browder jr &lt;browder@use1.eglin.af.mil&gt;
cc:       cad@ARL.MIL
Message-ID:  &lt;9502151910.aa20663@wolf.arl.mil&gt;

<p>

<p>
&gt; When attempting to select a region in "Object Illum", we get an error
&gt; message in mged that says:
&gt;
&gt; rt_id_solid: u_id=x43
&gt; rt_nul_import unimplemented
&gt; init_objedit(&lt;region name&gt;)
&gt;
&gt; The sequence ALWAYS occurs when we do the following in mged:
&gt;
&gt; E &lt;region name&gt;
&gt; E: &lt;n&gt; vectors in &lt;m&gt; sec
&gt;
&gt;
&gt; Then select "Object Illum"
&gt; highlight the region, select with the middle mouse button.
&gt;
&gt; Are we doing something wrong, though. Perhaps we shouldn't be editing
&gt; using E instead of e, or...?

<p>
Yes, editing only works if you view the object using the "e" command.
The "E" command and the "ev" command evaluate things below the region
level, and are not compatible with either Solid or Object editing.

<p>
I admit that it isn't a good error message.  Formerly there was a better
message, someone needs to find out why it no longer prints.  Probably
some new checking code got inserted before the old checking code.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa16638; 23 Feb 95 9:40 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id ad27737; 23 Feb 95 9:20 EST
Date:     Thu, 23 Feb 95 9:12:45 EST
From:     "W. Keith Bowman" (SURVICE|keith) &lt;wbowman@ARL.MIL&gt;
To:       Glenn Allison &lt;gda@msic.dia.mil&gt;
cc:       cad@ARL.MIL
Subject:  Re:  CAD4.4 compilation problems
Message-ID:  &lt;9502230912.aa27285@WALRUS.ARL.MIL&gt;

<p>
Glenn,
  The messages you are getting are from 'rld' the run time linker
which resolves dynamic shared objects. Under Irix5* the default
build uses shared libraries, which will really save you a lot of
disk space. The BRLCAD4.4 should be adding the '-rpath' option on
the link command followed by a path specifying where to find the
DSO's. Check to make sure that this this option is being used and
if so, check to make sure the path looks correct. If this option
is not being used run the the 'sh machinetype.sh -v' script and make
sure your machine is being recognized as 'MACHINE=6d'. If the path
looks incorrect check the setting of LIBDIR in 'Cakefile.defs'.
If you are not installing in the default '/usr/brlcad' directory
make sure to run the 'newbindir.sh' script which will replace
'/usr/brlcad' with new correct install location in several places
including 'Cakefile.defs'.
  Using the '-rpath' option on the load command puts the DSO
resolve path in the executable so be sure not to move your libraries
after the build. There are other ways to tell 'rld' where to
look but I think fixing the install is the best approach.

<p>
- Keith
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa17606; 1 Mar 95 15:52 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id ab06961; 1 Mar 95 14:44 EST
Received: from wharf.arl.mil by WALRUS.ARL.MIL id aa06912; 1 Mar 95 14:32 EST
Received: from 136.205.45.50 by wharf.arl.mil id aa25825; 1 Mar 95 14:08 EST
Received: by msic.dia.mil (4.1/SMI-4.1)
	id AA01695; Wed, 1 Mar 95 12:59:13 CST
Date: Wed, 1 Mar 1995 12:58:54 -0600 (CST)
From: Glenn Allison &lt;gda@msic.dia.mil&gt;
Subject: mged fb problem
To: cad@ARL.MIL
Message-Id: &lt;Pine.3.89.9503011240.B1671-0100000@msic.dia.mil&gt;
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

<p>
I am trying to get BRL-CAD running on a SUN SPARC 10 running SunOS 4.3.1.
The program compiles without any errors and mged works without any
trouble. I can create models with mged. I can ray-trace the models
without errors but when I try to display the pix file in the frame buffer
I get the following error:

<p>
	fb_open (0x8c70, "/dev/debug", 1024, 1024)
	fb_write (0x8c70,   0,    0,   0x8d50, 1024)
the last line is repeated for every line in the pix file.

<p>
any suggestions about this problem.

<p>

<p>
--Glenn Allison, MSIC, (205) 313-6251
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa13765; 14 Mar 95 9:20 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa14710; 14 Mar 95 8:21 EST
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa14631; 14 Mar 95 8:19 EST
Date:     Tue, 14 Mar 95 8:10:47 EST
From:     "John R. Anderson" &lt;jra@ARL.MIL&gt;
To:       Steve Pennock &lt;pennock@wichita.llnl.gov&gt;
cc:       CAD@ARL.MIL
Message-ID:  &lt;9503140810.aa12724@wolf.arl.mil&gt;

<p>
&gt; We have been using the ProE to BRL converter in the latest release of
&gt; the BRL-CAD package, and greatly appreciate its being included.  Now
&gt; the question has arisen as to whether anyone has developed a
&gt; capability to import BRL models into ProE.

<p>
Not yet, but I hope to provide such a capability in the not too distant
future.

<p>
&gt; We got a ProE model of an airplane from one of the airframe
&gt; manufacturers, converted it to MGED, then added a number of internal
&gt; features.  We'd like to ship those internal features back to ProE,
&gt; without having to re-create them in ProE.  Has anyone written anything
&gt; to allow this to be done?
&gt;
	You might try "g-iges" and then try importing the IGES file into
Pro-Engineer. That won't work on the version of Pro/E that I am running
(I still have version 13!!!), it expects only surface files, not solid models.
If Pro/E has improved its IGES capability beyond what was available in
version 13, there might be a chance.

<p>

<p>

John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa25612; 30 Mar 95 18:29 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa24849; 30 Mar 95 17:36 EST
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa24823; 30 Mar 95 17:33 EST
Date:     Thu, 30 Mar 95 17:29:59 EST
From:     "Lee A. Butler" &lt;butler@ARL.MIL&gt;
To:       glewis@pcocd2.intel.com
cc:       cad@arl.army.mil
Subject:  Re:  BRL questions
X-URL:    http://ftp.arl.mil/~butler/index.html
Message-ID:  &lt;9503301729.aa24737@wolf.arl.mil&gt;

<p>
&gt;1) Does XMGED support RIB output for RenderMan?

<p>
There is an outboard program to convert NMG solids
to RIB polygons.  It's called "nmg-rib".

<p>
&gt;2) Is there a port of XMGED for Linux boxes (without Motif)?

<p>
You'll have to run "mged".  XMGED requires MOTIF.

<p>
&gt;3) Are any models created for BRL-CAD available for viewing?
&gt;(Specifically, that Tank car on the BRL WWW pages look
&gt;really cool... and any other train-related ones?)

<p>
Look in the "db" directory of your distribution.  The ".asc" files there
can be turned into BRL-CAD binary databases using the asc-g program.

<p>
&gt;4) Since I am already a registered user of BRL-CAD, how can I
&gt;get the crypt key for the latest version?

<p>
I think your 4.0 decryption key will work on the 4.4 distribution.

<p>
Lee Butler
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa16099; 17 Apr 95 10:47 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id ab10494; 17 Apr 95 10:08 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa10490; 17 Apr 95 10:06 EDT
Date:     Mon, 17 Apr 95 10:05:49 EDT
From:     "John R. Anderson" &lt;jra@ARL.MIL&gt;
To:       URBANOWICZ@lvs-emh.lvs.loral.com
cc:       cad@brl.mil
Subject:  Re:  BRLCAD rtg3 question
Message-ID:  &lt;9504171005.aa15704@wolf.arl.mil&gt;

<p>
Jim Urbanowicz asks:

<p>
&gt; Is millimeters the only output unit of measure for rtg3?

<p>
	No. Actually, inches is the only output unit for RTG3.

<p>
&gt; If I call up a model inmged, and set the local units to inches,
&gt; then run the model through rtg3, will the line of sight thicknesses
&gt; for each ray trace be output in inches? Thanks.

<p>
	Yes. See above. Note that the "units" command in MGED only affects
what you see while running MGED. It specifies what units you want to work with
while using MGED with that particular model. The model is assumed to be stored
in mm and RTG3 uses a conversion factor to produce inches.

<p>

<p>

<p>
			-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa28403; 18 Apr 95 9:25 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa24873; 18 Apr 95 8:42 EDT
Received: from smokey.arl.mil by WALRUS.ARL.MIL id aa24823; 18 Apr 95 8:37 EDT
Date:     Tue, 18 Apr 95 8:34:00 EDT
From:     Bob Parker &lt;bparker@ARL.MIL&gt;
To:       james@delphi.dseg.ti.com
cc:       cad@ARL.MIL
Subject:  Re: xmged
Message-ID:  &lt;9504180834.aa21746@SMOKEY.ARL.MIL&gt;

<p>
James,

<p>
You can fix this by adding

<p>
  XMged*fontList: fixed

<p>
to an Xresource file (i.e. .Xdefaults) and then using
"xrdb -load .Xdefaults" to load this info into the
X server. Or you can edit dm-X.h by changing the corresponding
value in the fallback_resources and then recompiling.

<p>
Brl-cad release 4.4 already has these modifications.
If you haven't already done so, I'd recommend getting the
latest release. I hope this helps.

<p>
-Bob

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa23155; 25 Apr 95 16:26 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa13520; 25 Apr 95 15:31 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa13311; 25 Apr 95 15:21 EDT
Date:     Tue, 25 Apr 95 15:16:48 EDT
From:     "John R. Anderson" &lt;jra@ARL.MIL&gt;
To:       COOK-KM-KATHY &lt;cookkm@lvs-emh.lvs.loral.com&gt;
cc:       cad@ARL.MIL
Subject:  Re:  using NMG
Message-ID:  &lt;9504251516.aa22155@wolf.arl.mil&gt;

<p>
Kathryn M. Cook writes:

<p>
&gt;
&gt; I am familiar with creating BRLCAD models using the standard primitives.  I have
&gt; seen references in the mail traffic about NMG solids.  I have not been able to
&gt; locate any documentation on how to create and work with these solids.  Can they
&gt; be created and edited in xmged?

<p>
	The NMG solids are still experimental and not fully supported yet. You can make
an NMG solid of extrusion in MGED. The same should work in XMGED, but I don't
think it does. Here is the procedure:

<p>
	After starting MGED, make a nearly empty NMG solid by "make s.nmg nmg".
Replace "s.nmg" with any solid name you like. Then use the mouse to select "Solid
Ilum" (or type "press sill"). This will get you into Solid Edit Mode. Then use the
middle mouse button to select your NMG solid (or type "ill s.nmg"). This selects
the new NMG solid for editing. Next, select "pick edge" from the Solid Edit
Menu and move the mouse to the MGED display window (not in the menu) and click
the middle mouse button. This selects the only edge in the newly created NMG.
Now select "split edge" from the Solid Edit Menu. You may now draw a loop of
edges by clicking the middle mouse button at the locations of the desired points
(or use the "p" command). The result is a closed loop of edges. You may continue
to select edges, split edges, deletes edges, and move edges until you have the
shape you desire. When you are satisfied with the loop you have created, you
can extrude it by changing your viewing direction and selecting "extrude loop".
Clicking the middle mouse button will extrude the loop to the selected point.
You may continue selecting different points until you are satisfied with the
final NMG solid. Then select "Accept Edit" (or "press accept").

<p>
&gt; Is there any documentation on creating
&gt; polysolids (I also seen reference to these)?  I am familiar with FASTGEN
&gt; triangles and SHAZAM points and faces.  Do they work in a similar manner?  I
&gt; have used patch-g to translate my FASTGEN models but I can't figure out how to
&gt; edit the resulting faceted components or how to add additional similar
&gt; components.

<p>
	There is no way in MGED to create a polysolid, but you can write
a program that uses "libwdb" to create polysolids. You would need the following
routines:
	mk_id() to create an ID record for the new model.
	mk_polysolid() to make a header record for the polysolid
	mk_poly() or mk_fpoly() to make each face.
See libwdb/poly.c for these routines.

<p>
	The BRL-CAD polysolid is similar to the FASTGEN triangles in that
they both describe a solid by listing the vertices of planar faces. The
polysolid may have up to 5 vertices per face and does not have the sequencing
complication that FASTGEN triangular facets do. The polysolid faces must have their
vertices listed in CCW order (use the right-hand rule) so that the outward normal
is well defined.

<p>
&gt; Thanks,

<p>

<p>
	You're welcome. I hope this helps,

<p>

<p>
			-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa03436; 2 May 95 20:40 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa13656; 2 May 95 20:37 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa13565; 2 May 95 20:29 EDT
Date:     Tue, 2 May 95 20:20:19 EDT
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       Cheong Mei Teng &lt;cmeiteng@trantor.dso.gov.sg&gt;
cc:       CAD@ARL.MIL
Subject:  Re: latest BRLCAD
Message-ID:  &lt;9505022020.aa02843@wolf.arl.mil&gt;

<p>

<p>
&gt; &gt; This is possible even in release 4.0, using the '-X80000000' option
&gt; &gt; to RT and sending the output to "pl-sgi" or to a file, and then
&gt; &gt; viewing with "pl-sgi" or with the "overlay" command in "mged".
&gt; &gt;
&gt;
&gt; The platform that we are working on is Sun Sparc server 10, solaris 2.3.  I created a mged file trial.g containing a box and I tried to raytrace it using the following command:
&gt;
&gt;     rt -a90 -e0 -s32 trial.g box &gt; output.pix
&gt;
&gt; Next, I tried to see the interception animation by typing
&gt;     pix-fb output.pix
&gt;
&gt; I do not get an image file.  Instead, I got only lines of fb_open, fb_write and fb_close commands.  I had also tried viewing the pix file in mged using overlay command, but I still do not get any image.  Would appreciate very much if you could assist.

<p>
The problem here is that environment variable FB_FILE has not been
properly set.  Run "man brlcad" and read the section on FB_FILE.
Considering you are using Solaris, I suggest that you will get much
better results using the new versions of the display software in BRL-CAD
Release 4.4.

<p>
What this will show you is the optical image of the box.  In order
to see the ray history file, which is what I think you mean when you
say "interception animation", you need to do what I wrote earlier.
Try:

<p>
     rt -P1 -X80000000 -a90 -e0 -s32 -o output.pix trial.g box &gt; output.pl

<p>
Then view the ray history file in MGED like this:

<p>
	mged trial.g
	e box
	overlay output.pl

<p>
And then rotate the view as you please.

<p>
Best,
 -Mike
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa27279; 3 May 95 11:13 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa19584; 3 May 95 9:59 EDT
Date:     Wed, 3 May 95 9:48:46 EDT
From:     Bob Strausser (SURVICE Eng | SURVIAC ASO) &lt;strssr@ARL.MIL&gt;
To:       Rick Grote &lt;grote@ARL.MIL&gt;
cc:       ged@ARL.MIL
Subject:  Material ID Codes
Message-ID:  &lt;9505030948.aa19404@WALRUS.ARL.MIL&gt;

<p>
Rick,

<p>
The problem isn't with the geometries having different codes, its the
assessment models which use different codes.  For example ...

<p>
      MATERIAL      VAST         COVART            HEIVAM
      --------     ------       --------          --------
        1          steel        steel(BHN 100)    magnesium
        2          rha          steel(BHN 150)    aluminum
        3          fha          steel(BHN 200)    titanium
        4          cast iron    steel(BHN 250)    cast iron
        5          aluminum     steel(BHN 300)    fha
        6          magnesium    steel(BHN 350)    steel
        7          copper       titanium          rha
	etc.

<p>
So the material assigned in the target description is correct for a given
assessment model but if another analyst wants to use that geometry with a
different assessment model, all of the material code assignments must be
checked against the alternate model's understanding of what a material code
number of xx is.  This is also true for updated versions of assessment codes
(COVART 4 brought HEVART and HEIVAM internally so the material definitions
had to be made common).

<p>
This being the case, even with the ability to read the material ids from
the geometry database, the codes must still be verified to match whatever
assessment model is being used (and a conversion utility must still know
what id table was used in the geometry so it knows what id numbers to swap
to get to the desired id table).

<p>
Too good to pass up my two cents worth,

<p>
Bob Strausser
SURVICE Engineering

<p>

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa21785; 4 May 95 20:11 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa15906; 4 May 95 19:33 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa15875; 4 May 95 19:24 EDT
Date:     Thu, 4 May 95 19:21:04 EDT
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       iedsp@agt.gmeds.com
cc:       CAD@ARL.MIL
Subject:  Re: BRLCAD
Message-ID:  &lt;9505041921.aa20232@wolf.arl.mil&gt;

<p>

<p>
Dave asks -

<p>
&gt; Is the free unsupported version of brlcad the same as the supported
&gt; version (the source code)?

<p>
The software provided is identical in either case.  The only difference
is human time and supplies:

<p>
*)  Select the FREE distribution if (a) you have InterNet FTP access +and+
(b) you don't need assistance installing/configuring/using the software.

<p>
*)  Select the SUPPORTED distribution if (a) you need the software on
tape -or- (b) you desire assistance installing/configuring/using the
software.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa18774; 13 Jun 95 11:05 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id ab13094; 13 Jun 95 11:03 EDT
Received: from wharf.arl.mil by WALRUS.ARL.MIL id aa12948; 13 Jun 95 10:53 EDT
Received: from cs.ida.org by wharf.arl.mil id aa04699; 13 Jun 95 10:39 EDT
Received: from oed-u1.oed.ida.org by ida.org (4.1/SMI-4.1)
	id AA01981; Tue, 13 Jun 95 10:38:56 EDT
Received: from bturner-pc (bturner-pc.oed.ida.org) by oed-u1.oed.ida.org (4.1/SMI-4.1)
	id AA05857; Tue, 13 Jun 95 10:38:54 EDT
From: Ben Turner &lt;bturner@ida.org&gt;
Message-Id: &lt;9506131039.ZM10807@bturner-pc&gt;
Date: Tue, 13 Jun 1995 10:39:28 -0400
In-Reply-To: Mike Muuss &lt;mike@ARL.MIL&gt;
        "Re: HTML to PS?" (Jun 12,  5:42pm)
References: &lt;9506121742.aa19876@wolf.arl.mil&gt;
X-Mailer: ZM-Win (3.2.1 09Sep94)
To: iedsp@agt.gmeds.com
Subject: Re: HTML to PS?
Cc: cad@ARL.MIL
Mime-Version: 1.0
Content-Type: multipart/mixed;
	boundary="PART-BOUNDARY=.19506131039.ZM10807.bturner-pc"

<p>

<p>
--PART-BOUNDARY=.19506131039.ZM10807.bturner-pc
Content-Description: Text
Content-Type: text/plain ; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Zm-Decoding-Hint: mimencode -q -u

<p>
On Jun 9,  9:46am, David S. Pesetsky wrote:
&gt; Subject: HTML to PS?
&gt; I'm looking for a way to convert the HTML pages that come with the
&gt; distribution to postscript so I can print them all at once.
&gt;-- End of excerpt from David S. Pesetsky

<p>
You may find Jan K=E4rrman's html2ps perl script useful.  I've used it with
perl versions 5.001 and 4.0 (the latter is distributed with SGI IRIX 5.3).
This script does not handle in-line images (substitutes [IMAGE]).

<p>
Exerpt from the html2ps info page &lt;http://www.tdb.uu.se/~jan/html2ps.html&gt;:
| The Perl script html2ps is an HTML-to-PostScript converter. Perl is
| available from any comp.sources.misc archive.
|
| The latest version of html2ps is available via anonymous ftp from
| ftp.tdb.uu.se in /pub/sources/html2ps as a tar file:
| html2ps_0.1beta.tar. You can also fetch the files individually from
| the same directory: README, html2ps,, html2ps.1 (a manual page) and
| manpage.txt (a plaintext version of the manual page).

<p>
Best,
Ben

<p>

<p>

<p>

<p>
--PART-BOUNDARY=.19506131039.ZM10807.bturner-pc--

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa07260; 16 Jun 95 10:47 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa03695; 16 Jun 95 9:25 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa03616; 16 Jun 95 9:20 EDT
Date:     Fri, 16 Jun 95 9:20:09 EDT
From:     Glenn Durfee &lt;gdurf@ARL.MIL&gt;
To:       ZEROMOLD@aol.com
cc:       cad@ARL.MIL
Subject:  Re:  tmged not working
Message-ID:  &lt;9506160920.aa03482@wolf.arl.mil&gt;

<p>
Phil Cogan (ZEROMOLD@aol.com) writes:
&gt; I've been using mged for a couple of months and recently tired compiling
&gt; tmged. The compile went smoothly, however when I went to run tmged, all I
&gt; got was was a blank window itled Tkmged and the standard mged window.
&gt;
&gt; All the tcl/Tk demos work flawlessly.
&gt;
&gt; What did I do wrong?

<p>
To try out the sample user interface, you need to do the following:
Find "tmged.tcl" (it should be in the tmged directory.  For this
example, we will assume it is in the subdirectory "../tmged").
Then, at the mged&gt; prompt, type "source ../tmged/tmged.tcl" (or whatever
path is appropriate).  You should then get the sample interface (a
button menu and an interaction window).

<p>
The main reason the interface is not loaded automatically is that users
may wish to write their own, customized, interfaces in Tcl/Tk for use
in tmged.

<p>
If you want this to be loaded automatically each time you start tmged,
copy "tmged.tcl" to "~/.tmgedrc" (or put the "source foo/tmged.tcl" command
in your ~/.tmgedrc file).

<p>
Hope this helps,
Glenn
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa05039; 15 Jul 95 5:05 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa12899; 15 Jul 95 4:26 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa12892; 15 Jul 95 4:16 EDT
Date:     Sat, 15 Jul 95 4:07:51 EDT
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       CAD@ARL.MIL
Subject:  near-real-time raytracing
Message-ID:  &lt;9507150407.aa03596@wolf.arl.mil&gt;

<p>

<p>
This evening I got the prototype versions of RTSYNC and RTNODE running.
Right now I've got 3 systems with a total of 38 CPUs rendering the
viewpoint from my MGED session as fast as they can into a shared
framebuffer.  I'm getting about 0.5 frames/sec, at 512x512, and that
isn't close to the final number of CPUs....

<p>
I set the MGED to spinning, and it's really cool to watch the
framebuffer flipping up a new image every other second, fully ray-traced.

<p>
Until the HIPPI framebuffer gets installed, I think I'm going to be
Ethernet limited....  Ugh.

<p>
	Progress!
	 -Mike
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa15170; 27 Jul 95 18:45 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa24370; 27 Jul 95 17:59 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa24368; 27 Jul 95 17:54 EDT
Date:     Thu, 27 Jul 95 17:51:22 EDT
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       CAD@ARL.MIL
Subject:  pathlist command added to MGED
Message-ID:  &lt;9507271751.aa13107@wolf.arl.mil&gt;

<p>

<p>
This evening I added the "pathlist" command to MGED at the request of
Glenn Durfee.  This new command makes it easy for TCL functions to build
menus containing the list of paths below a given combination.

<p>
With Glenn working on TCL/Tk "power functions" for creating new
geometry, and with PJT working on a TCL/Tk "power function" for
point-n-click solid editing, I'm really excited about where MGED is
heading!

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa29758; 28 Jul 95 3:57 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa28373; 28 Jul 95 3:50 EDT
Received: from vapor.arl.mil by WALRUS.ARL.MIL id aa28363; 28 Jul 95 3:44 EDT
Date:     Fri, 28 Jul 95 3:36:59 EDT
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       CAD@ARL.MIL
Subject:  OED cmd added to MGED
Message-ID:  &lt;9507280336.aa16976@VAPOR.ARL.MIL&gt;

<p>

<p>
This evening I added the "OED" command to MGED, allowing a direct
transition from VIEW state to ObjectEdit state in one step, without
having to go through the steps of "press oill", "ill leaf", and "matpick
a/b".

<p>
This should further improve our ability to drive MGED from TCL scripts.

<p>
Usage is "oed path_lhs path_rhs"

<p>
Examples:  "oed all.g box.r/box.s" and "oed all.g/box.r box.s"

<p>
The matrix which will recieve the object edit transform is located
at the implicit slash where the space between path_lhs and path_rhs.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa06456; 24 Aug 95 3:47 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa06609; 24 Aug 95 2:43 EDT
Received: from vapor.arl.mil by WALRUS.ARL.MIL id aa06607; 24 Aug 95 2:38 EDT
Date:     Thu, 24 Aug 95 6:29:08 GMT
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       CAD@ARL.MIL
Subject:  TCL MGED mouse bindings
Message-ID:  &lt;9508240629.aa03301@VAPOR.ARL.MIL&gt;

<p>

<p>
In the experimental version of TCL MGED I've changed the internal
handling of the left and right mouse buttons.  They now generate "L" and
"R" commands with the same syntax as the "M" middle-mouse command.
The default bindings are for zoom-in and zoom-out as before, but
this new arrangement allows users to re-bind the mouse buttons as
they wish.  For example, to make all three buttons act as the middle
mouse has always done, these two commands would suffice:

<p>
proc L {up x y} {_mged_M $up $x $y}
proc R {up x y} {_mged_M $up $x $y}

<p>
        Best,
         -Mike
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa04944; 23 Oct 95 17:58 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa22696; 23 Oct 95 17:15 EDT
Date:     Mon, 23 Oct 95 17:08:26 EDT
From:     Bob Strausser (SURVICE Eng | SURVIAC ASO) &lt;strssr@ARL.MIL&gt;
To:       COOK-KM-KATHY (156791) &lt;cookkm@lvs-emh.lvs.loral.com&gt;
cc:       cad@ARL.MIL
Subject:  rtweight program
Message-ID:  &lt;9510231708.aa22428@WALRUS.ARL.MIL&gt;

<p>
Kathy,

<p>
The rtweight program is part of the distribution but it is not compiled
in the default configuration.  The reference program is in the "rt"
directory called "viewweight.c".  You will need to modify the cakefile
to compile the program.  It compiles and runs on the SGI without problem.

<p>
reposted for your information:
********************************************************************
Date:     Thu, 12 Jan 95 12:31:32 GMT
From:     Jim Hunt &lt;jehunt@arl.mil&gt;
Subject:  Re: rtweight
Message-ID:  &lt;9501120731.aa07047@whim.arl.mil&gt;

<p>
Rtweight was a piece of sample code to show one way that weights and
centroids can be calculated using librt.  It is not very "portably"
written and thus not part of a standard compile.  Find it under your
source tree in the rt directory (file name "viewweight.c").  Here is
the patch for the Cakefile if you want to try to compile it:

<p>
*** Cakefile.orig	Thu Jan  5 08:56:04 1995
--- Cakefile	Thu Jan 12 07:27:14 1995
***************
*** 8,14 ****
  #define SRCDIR	rt
  #define PRODUCTS	rt rtrad rtpp rtray rtshot rtwalk rtcheck \
  			rtg3 rtcell rtxray rthide rtfrac rtrange \
! 			rtregis rtscale
  #define	SRCSUFF	.c
  #define MANSECTION	1

--- 8,14 ----
  #define SRCDIR	rt
  #define PRODUCTS	rt rtrad rtpp rtray rtshot rtwalk rtcheck \
  			rtg3 rtcell rtxray rthide rtfrac rtrange \
! 			rtregis rtscale rtweight
  #define	SRCSUFF	.c
  #define MANSECTION	1

***************
*** 40,45 ****
--- 40,52 ----
  	CC CFLAGS -c vers.c
  	CC LDFLAGS RT_OBJ vers.o LIBRT LIBFB LIBFB_LIBES LIBRT_LIBES LIBES -o rt

+
+ #define RTWEIGHT_OBJ	RTUIF viewweight.o
+
+ rtweight:	RTWEIGHT_OBJ LIBRT_DEP LIBFB_DEP
+ 	sh ../newvers.sh version "RT Weight"
+ 	CC CFLAGS -c vers.c
+ 	CC LDFLAGS RTWEIGHT_OBJ vers.o LIBRT LIBFB LIBFB_LIBES LIBRT_LIBES LIBES -o rtweight

  #define RTRAY_OBJ	RTUIF viewray.o wray.o

********************************************************************

<p>
Bob Strausser
SURVIAC ASO

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa18339; 30 Nov 95 23:17 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa19124; 30 Nov 95 22:09 EST
Received: from warp.cs.unc.edu by WALRUS.ARL.MIL id aa19095; 30 Nov 95 21:59 EST
Date:     Thu, 30 Nov 95 21:59:37 EST
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       CAD@ARL.MIL
Subject:  LIBNURB data structure conversion
Message-ID:  &lt;9511302159.aa04906@WILSON.ARL.MIL&gt;

<p>

<p>
Today Paul Stay and I converted all the routines in LIBNURB over to
using the t-NURBS data structures from the NMG package.  Thus, all
"snurb" structures are now "face_g_snurb", and all "cnurb" structures
are now "edge_g_cnurb".

<p>
This means that routines in MGED and LIBRT can directly use the LIBNURB
routines for processing t-NURBS NMG objects.  This has been imporant
for us to have in furthering our trimmed-NURBS capability, and is
an (overdue) good thing to do.

<p>
For those of you who may have programmed using the old LIBNURB data
structures, when you get the new code (currently found only in the
development tree), you can use the attached "ed" script to convert
your code over to the new form.

<p>
	Best,
	 -Mike

<p>

<p>
f
g/u_knots/s//u/gp
g/v_knots/s//v/gp
g/struct cnurb/s//struct edge_g_cnurb/gp
g/struct snurb/s//struct face_g_snurb/gp
g/ cnurb/s// edge_g_cnurb/gp
g/ snurb/s// face_g_snurb/gp
g/knots/s//__KNOTS__/g
g/\\.knot/s//.k/gp
g/-&gt;knot/s//-&gt;k/gp
g/__KNOTS__/s//knots/g
f
w
q
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa14196; 3 Dec 95 16:39 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa14152; 3 Dec 95 15:54 EST
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa14138; 3 Dec 95 15:47 EST
Date:     Sun, 3 Dec 95 15:44:25 EST
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       Arthur Blair &lt;blair@mkserv.dseg.ti.com&gt;
cc:       cad@ARL.MIL
Subject:  Re: trouble with raytracer.
Message-ID:  &lt;9512031544.aa11086@wolf.arl.mil&gt;

<p>

<p>
The key to your difficulty is highlighted by the message:

<p>
fb_open( 0x3e000, "/dev/debug", 512, 512 )

<p>
This means that you neglected to set your FB_FILE environment variable.

<p>
Check out "man brlcad", and "man 3 libfb".  You might also try
running the "fbhelp" program to get it's (extensive) help message.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from smokey.arl.mil by wolf.arl.mil id aa17032; 4 Dec 95 9:25 EST
Date:     Mon, 4 Dec 95 9:25:49 EST
From:     Jim Rapp &lt;rapp@ARL.MIL&gt;
To:       jjs@mech2.snu.ac.kr
cc:       mike@ARL.MIL
Subject:  Optimetrics Contact
Message-ID:  &lt;9512040925.aa20185@SMOKEY.ARL.MIL&gt;

<p>
The FRED code distribution is handled out of the Dayton, Ohio office of
Optimetrics.  The point-of-contact for FRED distribution is Susie Pryce. Her
phone number is 513-264-1466.  The FAX number there is 513-264-1414.

<p>
I hope this information helps.

<p>

<p>
Jim Rapp
<hr>
<hr>
Received: from vapor.arl.mil by wolf.arl.mil id aa08426; 15 Dec 95 0:40 EST
Date:     Fri, 15 Dec 95 0:36:46 EST
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       ACST@ARL.MIL
cc:       Phil@ARL.MIL
Subject:  pixhalve improved
Message-ID:  &lt;9512150036.aa02554@VAPOR.ARL.MIL&gt;

<p>

<p>
I've updated the source to pixhalve, so that it now converts from
RGB to YUV, then applies a 3x3 filter to Y and a 5x5 filter to U and V,
so as to preserve the maximum amount of detail when the destination
is NTSC television, the main application of this tool.

<p>
It does make a difference, but for the Bradley image that I tried it on,
it's very subtle.  Perhaps in other images it will be more beneficial.
In any case, I'm leaving the code installed.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from vapor.arl.mil by wolf.arl.mil id aa12025; 15 Dec 95 1:30 EST
Date:     Fri, 15 Dec 95 1:21:50 EST
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       ACST@ARL.MIL
cc:       Phil@ARL.MIL, CJohnson@camelot.com
Subject:  pix-yuv, yuv-pix
Message-ID:  &lt;9512150121.aa02819@VAPOR.ARL.MIL&gt;

<p>

<p>
I've created two new utilities, pix-yuv and yuv-pix.  They write
Abekas-compatible .yuv files.  This provides some additional options
for dealing with Abekas files.

<p>
It uses the same code as libfb/if_ab.c

<p>
	Best,
	 -Mike
<hr>
<hr>
Date:     Fri, 15 Dec 95 8:38:23 EST
From:     Paul Tanenbaum  &lt;pjt@arl.mil&gt;
To:       acst@arl.mil
Subject:  bary(1)
Message-ID:  &lt;9512150838.aa11349@wolf.arl.mil&gt;

<p>

<p>
     I've created a new utility, called bary, to compute weighted sums of
points in 3-space.  You specify "sites" on the command line and then in
the input stream you give lines of one-weight-per-site.  It has options to
normalize the weights (thus giving you barycentric combinations of the
sites) and to copy unmolested any/all fields beyond the first three.
     The motivation was PHD's request for a ray-traced plot of unit cube
data into an equilateral triangle.  I can easily imagine other such
visualization applications where the tool would be of use.
     And, most surprising, it even has a man page.
     Paul

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa20444; 27 Dec 95 10:22 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa23511; 27 Dec 95 9:01 EST
Date:     Wed, 27 Dec 95 8:49:15 EST
From:     Bob Strausser (SURVICE Eng | SURVIAC ASO) &lt;strssr@ARL.MIL&gt;
To:       jung jinsoo &lt;jjs@mech2.snu.ac.kr&gt;
cc:       cad@ARL.MIL
Subject:  BRL-CAD from IGES5.1
Message-ID:  &lt;9512270849.aa23266@WALRUS.ARL.MIL&gt;

<p>
The IGES5.1 support is designed for basic solid entities and for spline
surfaces.  It will also import an IGES5.1 drawing entity (option -d) which
you can position to use as a view template.  A minimum of two templates
(front and side, top and side, back and bottom, etc.) are required to provide
the l-w-h data for each of the solids you will build from the templates.  The
templates if viewed from its "side" will be a single line (like the edge of
a piece of paper) but from its "face" will provide a transparent line drawing
guide (with dimensions if in the original IGES5.1 drawing).

<p>
Bob Strausser
The SURVIAC ASO
<hr>
<hr>
Date: Tue, 20 Feb 1996 09:30:58 -0500 (EST)
From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" &lt;jra@arl.mil&gt;
To: acst@arl.mil
Subject: New command in MGED
Message-ID: &lt;Pine.SGI.3.91.960220092249.27009A-100000@wolf.arl.mil&gt;
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: jra@arl

<p>

<p>
	I have added a new command to MGED. The command is
"nmg_simplify" This takes an existing NMG solid and attempts to
represent it as a simpler BRL-CAD primitive and build that simpler
solid. Currently, it can recognize arb4's through arb8's and circular
cross section cones and cylinders. The syntax is:

<p>
	nmg_simplify [arb|tgc|poly] new_solid existing_nmg_solid

<p>
The default behavior is to attempt to build and arb first, if that is
not possible, it attempts a tgc, and if that is also not possible, the
last resort is to build a polysolid. If an optional arguement is
provided, then only that particular type of solid is attempted.

<p>
	This command was inspired by a request from Bill Hruz and
uses routines developed for the Pro/E to BRL-CAD translater.

<p>
		-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa12099; 22 Feb 96 16:32 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa13191; 22 Feb 96 15:02 EST
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa13123; 22 Feb 96 14:55 EST
Date: Thu, 22 Feb 1996 14:51:11 -0500 (EST)
From: "Lee A. Butler" &lt;butler@ARL.MIL&gt;
To: "David J. Yemc" &lt;yemc@aplcore.jhuapl.edu&gt;
cc: cad@ARL.MIL
Subject: Re: HF solids
In-Reply-To: &lt;9602212230.AA22519@aplcore.jhuapl.edu&gt;
Message-ID: &lt;Pine.SGI.3.91.960222143909.21188A-100000@wolf.arl.mil&gt;
X-URL: http://ftp.arl.mil/~butler/
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: butler@ARL.MIL

<p>
On Wed, 21 Feb 1996, David J. Yemc wrote:
&gt; I am trying to work with the HF solid in BRL-CAD, v4.4 running on a DEC alpha.
...
&gt; Can anyone point me in the proper direction?

<p>
I've worked with the hf.  There are some problems with ray-tracing the
hf with the released version.

<p>
My height field is a 257x257 array of unsigned shorts (2 byte int).

<p>
mged&gt; in hff.s hf dfile="01.hf" fmt="us" w=257 n=257 shorts=1 file2mm=31.25
v=0,0,0 x=1,0,0 y=0,1,0 xlen=256000 ylen=256000 zscale=1

<p>
That should all be typed in on one line, but I've broken the line for
readability.  As far as I can tell this means:

<p>
	dfile="01.hf"		The data is in the file "01.hf"
	fmt="us"		The data is unsigned shorts
	w=257			257 samples wide
	n=257			257 samples long
	shorts=1		1 short per sample
	file2mm=31.25		heights are multiplied by 31.25 to get mm size
	v=0,0,0			origin of HF is at 0,0,0
	x=1,0,0			X axis aligned along 1,0,0
	y=0,1,0			Y axis aligned along 0,1,0
	xlen=256000		X axis is 256000mm
	ylen=256000		Y axis is 256000mm
	zscale=1		Heights are not scaled

<p>
Lee Butler

<p>
Lee A. Butler
Attn: AMSRL-SL-BV				Internet: butler@arl.mil
U.S. Army Research Laboratory			Phone: (410) 278-9200
Aberdeen Proving Ground, MD  21005-5068		FAX:   (410) 278-5058

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa22013; 12 Mar 96 12:36 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa13426; 12 Mar 96 12:33 EST
Received: from worm.arl.mil by WALRUS.ARL.MIL id aa13316; 12 Mar 96 12:24 EST
From: "Gary S. Moss" &lt;moss@ARL.MIL&gt;
Message-Id: &lt;9603121219.ZM3159@arl.mil&gt;
Date: Tue, 12 Mar 1996 12:19:12 -0500
In-Reply-To: "Thomas M. Browder Jr." &lt;browder@eglin.af.mil&gt;
        "burst" (Mar 12,  9:32am)
References: &lt;199603121532.JAA06062@use1.eglin.af.mil&gt;
X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail)
To: "Thomas M. Browder Jr." &lt;browder@eglin.af.mil&gt;, cad@ARL.MIL
Subject: Re: burst
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: moss@ARL.MIL

<p>
On Mar 12,  9:32am, Thomas M. Browder Jr. wrote:
&gt; Subject: burst
&gt; I am having trouble trying to produce the documents available with the
&gt; burst package. Is it possible to have a README file, or something similar,
&gt; to give the instructions for the proper syntax for appropriate troff
&gt; commands? The same goes for the 'talk' subdirectory where it appears there
&gt; is an interesting paper, but no clue for novices about how to produce it.

<p>
Tom,
	It's been lots of years since typesetting of these documents has
been attempted by me (the author), and I can't test it out conveniently
because I'm no longer familiar with how/which TROFF fonts and macro packages
are configured on our various workstations and servers.  However, if you
have a troff capability, it used to work as follows:

<p>
	1) For burst/paper, typeset with a command like:

<p>
		"troff -mm -T[printer] paper.mm"

<p>
	where the [printer] selects the target printer type (ie -Ti300 for an
	300 DPI Imagen).  This assumes that the ".tbl" files have been
	preprocessed with there ".mm" source files (ie "tbl ids.tbl &gt; ids.mm").
	Note that "paper.mm" sources all other needed files.

<p>
	2) For burst/talk, you need to use the "mv" macros instead of "mm" on
	and run troff on each ".mv" source file:

<p>
		"troff -mv -T[printer] *.mv"

<p>
	If you have a "domv" script in that directory, it is intended to be
	used like so:

<p>
		"domv [file]"

<p>
	where [file] is missing the ".mv" suffix.  This script would need to
	be changed to select the proper printer, etc.  Currently it pipes the
	output through "dimp" which is a Device Independent Troff preprocessor
	for the Imagen printers, and then it pipes the result to "ipr" which
	is our Imagen spooler.

<p>
If you have problems, perhaps someone who still uses TROFF can be of more
help.  NOTE that the burst paper is published in at least one BRL-CAD
Symposium Proceedings and if you have the set of blue manuals that came out
with BRL-CAD Release 4.0 and beyond, it's in Volume III, The BRL-CAD
Applications, on a page marked "88" at the bottom, also "V3S07A00" in the
lower right corner (the page numbering is extremely not useful in this
document).

<p>
Hope this helps,
-Gary

<p>

<p>

<p>
--

<p>
   _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
  _/       Gary S. Moss         email:  moss@arl.mil              _/
 _/  Computer Scientist         WWW:    http://web.arl.mil/~moss _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa04801; 6 Jun 96 10:23 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa11402; 6 Jun 96 10:18 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa11392; 6 Jun 96 10:16 EDT
Date: Thu, 6 Jun 1996 10:08:59 -0400 (EDT)
From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" &lt;jra@ARL.MIL&gt;
To: "COOK-KM-KATHY (156791)" &lt;cookkm@lvs-emh.lvs.loral.com&gt;
cc: cad@ARL.MIL
Subject: Re: BRLCAD to VRML/IV converter
In-Reply-To: &lt;9606051330.ZM25120@daggit.lvs.loral.com&gt;
Message-ID: &lt;Pine.SGI.3.91.960606095327.1305A-100000@wolf.arl.mil&gt;
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: jra@ARL.MIL

<p>
On Wed, 5 Jun 1996, COOK-KM-KATHY (156791) wrote:

<p>
&gt; Does there exist any method or routine to convert a BRLCAD geometry to
&gt; VRML/Open Inventor(*.iv) format?  The platform indepentent VRML viewers and
&gt; open inventor routines (which come with SGIs) would provide a convienent way to
&gt; display/present a solid read-only representation of a BRLCAD model without
&gt; ray-tracing multiple views.
&gt;
&gt; SGIs Showcase software will allow open inventor files to be embedded into a
&gt; presentation.  The geometric model can then be positioned to any convienent
&gt; view at will using the mouse.  Future versions of other presentation software
&gt; will probably allow insertion of VRML objects.
&gt;
&gt; Are there any plans to develop such a tool in a future release of BRLCAD?  I
&gt; assume this would require exporting a representation of the evaluated objects
&gt; in a form similar to nmg.

<p>
	There is a primitive "g-vrml" converter that will be in the next
release of BRL-CAD. It is primitive in that it does not take advantage of
all the capabilities of VRML. It does handle the geometry, and colors,
but all light sources are reduced to point sources. Also relfection,
transparency and textures are not handled yet (I don't recall how
much of that VRML will actually do). You are correct in your expectation
that this would require exporting a representation of the evaluated
objects in a form similar to nmg. In fact, the converter produces NMG
objects, then outputs them in VRML format. This means that "g-vrml" will
only convert what our NMG codes can successfully handle, and while this
is not 100%, recently we have seen about 95% success.

<p>
			-John

<p>

<p>

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058

<p>
AMC says that my views do not represent an official Government position.

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa24473; 8 Jun 96 12:06 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa11643; 8 Jun 96 10:57 EDT
Received: from admii.arl.mil by WALRUS.ARL.MIL id aa11636; 8 Jun 96 10:51 EDT
Received: from NORMAN.VI.RI.CMU.EDU by ADMII.ARL.MIL id aa00190;
          8 Jun 96 10:44 EDT
Received: from nageela.vi.ri.cmu.edu by NORMAN.VI.RI.CMU.EDU (8.6.10/NX3.0M)
	id KAA10200; Sat, 8 Jun 1996 10:44:32 -0400
From: Robert Thibadeau &lt;rht@norman.vi.ri.cmu.edu&gt;
Message-Id: &lt;199606081444.KAA10200@NORMAN.VI.RI.CMU.EDU&gt;
Received: by nageela.vi.ri.cmu.edu (8.6.10/NX3.0X)
	id KAA07320; Sat, 8 Jun 1996 10:44:31 -0400
Date: Sat, 8 Jun 1996 10:44:31 -0400
To: cad@ARL.MIL
Subject: html on net

<p>
I wrote some software and have made it free to
download at www.ontv.com called "webfetcher" that
should work for anybody that needs to download
large manual/code sets from the web.   It runs
on most all platforms.  Not pretty, but it should
work pending a CD run.
I am a serious fan of not cutting down trees.
<hr>
<hr>
Date: Wed, 12 Jun 1996 09:53:30 -0400 (EDT)
From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" &lt;jra@ARL.mil&gt;
To: acst@ARL.mil
Subject: New field in application structure
Message-ID: &lt;Pine.SGI.3.91.960612094353.27971A-100000@wolf.arl.mil&gt;
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: jra@arl

<p>

<p>
	I have added an "a_ray_length" field to librt's application
structure. This is intended to work similar to "a_onehit", and has been
implemented in much the same way. If this field is set to a non-zero
value, then ray tracing is stopped as soon as we get beyond the
"a_ray_length". The raytracing is done in increments of the space
partitions, so this will not stop at exactly "a_ray_length", but it will
stop before raytracing any space partition beyond "a_ray_length". I
tested this out on the bradley and found that it works as I expected and
does in fact reduce the time. Of course, if this is used on a very
simple model, you will actually increase the raytrace time.

<p>
	Both "a_ray_length" and "a_onehit" can be specified and raytracing
will stop as soon as either one is satisfied.

<p>

<p>
			-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058

<p>
AMC says that my views do not represent an official Government position.

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa09181; 15 Jul 96 14:55 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa04828; 15 Jul 96 13:30 EDT
Received: from admii.arl.mil by WALRUS.ARL.MIL id aa04625; 15 Jul 96 13:21 EDT
Received: from dfw-ix6.ix.netcom.com by ADMII.ARL.MIL id aa12839;
          15 Jul 96 13:05 EDT
Received: from [205.186.74.81] (ven-ca2-17.ix.netcom.com [205.186.74.81]) by dfw-ix6.ix.netcom.com (8.6.13/8.6.12) with SMTP id KAA08237 for &lt;cad@brl.mil&gt;; Mon, 15 Jul 1996 10:05:04 -0700
X-Sender: MWarner1@popd.ix.netcom.com (Unverified)
Message-Id: &lt;v01540b00ae0f5384fb45@[205.186.74.73]&gt;
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 15 Jul 1996 10:11:29 -0700
To: cad@brl.mil
From: Matt Warner &lt;MWarner1@ix.netcom.com&gt;
Subject: Free Unix now on Apple PPC machines

<p>
For anyone out there using BRL-CAD, there is finally a Unix flavor
available natively for the PowerPC-based Apple Macintosh.  Specifically, it
is mklinux running on a Mach microkernel.  Currently, it only runs on
PPC601 chips (PM 6100, 7100, 8100), and the official release is in
September.  It is possible to purchase a reference release on CD for $10
now or download the rather large files online.  Anyone interested should
see these sites:

<p>
http://www.mklinux.apple.com
and
http://www.gr.osf.org/~stephen/linux.html

<p>
If anyone does successfully port BRL-CAD to MkLinux, please let me know.

<p>
Matt Warner

<p>
<hr>
Your unOfficial Macintosh Guy

<p>

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa23183; 19 Jul 96 23:56 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa25005; 19 Jul 96 23:54 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa24992; 19 Jul 96 23:44 EDT
Date:     Fri, 19 Jul 96 23:43:06 EDT
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       Henri Lelong &lt;lelong@logique.jussieu.fr&gt;
cc:       CAD@brl.mil
Subject:  Re: mged
Message-ID:  &lt;9607192343.aa22277@wolf.arl.mil&gt;

<p>

<p>
&gt; I got the embarrassing problem of having .g files, but no adequate version of
&gt; g2asc for them, although I still have the right machine (a SGI iris3130) !
&gt; My .g files were made with mged version 3.7, and I do not have this version
&gt; handy.

<p>
It turns out that you are in luck -- I grew up in an IBM mainframe
envirnoment (long ago), and upwards compatability is something that I
work hard to maintain in BRL-CAD.

<p>
Binary ".g" databases from BRL-CAD Release 2.0, 2.3, 3.0, 3.7, 4.0, and
4.4 are all upwards compatible, meaning that databases created on
software with a smaller number can be read with more recent software.

<p>
(The reverse is sometimes, but NOT ALWAYS true -- if you write a
database on a higher numbered version of the software, it may or may not
be readable by a lower numbered version, depending on whether you happen
to invoke any of the newer features or not.)

<p>
Also, the ".g" format databases are directly binary compatible between
SGI 3030, SGI "4-D", Sun-3, Sun-4 (SPARC), and Alliant computers.

<p>
So you can just move your old ".g" file from the SGI 3030 onto a modern
SGI or Sun workstation running Release 4.4, and pick up where you left
off.

<p>

<p>
	Best,
	 -Mike Muuss

<p>
	  Senior Computer Scientist
	  Ballistic Vulnerability/Lethality Division
	  Survivability and Lethality Analysis Directorate
	  The U.S. Army Research Laboratory
	  Attn: AMSRL-SL-BV
	  APG, MD  21005-5068  USA

<p>
	  My E-mail is &lt;Mike @ ARL.MIL&gt;
	  My World-Wide-Web URL is http://ftp.arl.mil/~mike/

<p>
	  410-278-6678 Voice
	  410-278-6656 Secretary
	  410-278-5058 FAX
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa12211; 25 Jul 96 18:57 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa19199; 25 Jul 96 18:04 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa19164; 25 Jul 96 17:54 EDT
Date:     Thu, 25 Jul 96 17:53:24 EDT
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       Carl Moore &lt;cmoore@ARL.MIL&gt;
cc:       cad@ARL.MIL
Subject:  Re: function keys
Message-ID:  &lt;9607251753.aa08076@wolf.arl.mil&gt;

<p>

<p>
Carl wrote -

<p>
&gt; In mged (at least the way I have it here at ARL), there are some functions
&gt; available on the Function keys on a Silicon Graphics terminal.

<p>
&gt; I do not see any description of these in the on-line help provided in mged.

<p>
These are SGI-specific features.

<p>
On an SGI, you can get information about any of the buttons and knobs in
MGED by pressing and holding the HELP button on the button box (upper
left button), then pressing the button or twisting the knob you want
help on.

<p>
Here is a quick summary:

<p>
F1	Toggle depthcueing
F2	Toggle Z-clipping
F3	Toggle perspective on/off
F4	Toggle Z-buffering
F5	Toggle Lighting model (flat -vs- smooth shaded polygons)
F6	Select next perspective angle from list: 30, 45, 60, 90 degrees
F7	Toggle MGED faceplate off/on
F8	Toggle menu
F12	Zaps knobs/sliders back to zero

<p>
You can ascertain the status of the vendor-specific features currently
in effect by running the command "dm set" -- that will print the
vendor-specific settings of the current display manager.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa10044; 20 Aug 96 18:21 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa26972; 20 Aug 96 16:00 EDT
From: "Bill Mermagen Jr." &lt;wm@ARL.MIL&gt;
Message-Id: &lt;9608201551.ZM12622@arl.mil&gt;
Date: Tue, 20 Aug 1996 15:51:46 -0400
In-Reply-To: wm@arl.mil (Bill Mermagen Jr.)
        "Re: Patch-g bug report" (Aug 14,  4:18pm)
References: &lt;199608082134.QAA20549@use1.eglin.af.mil&gt;
	&lt;9608141618.ZM3553@arl.mil&gt;
X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail)
To: kelsey@eglin.af.mil
Subject: Re: Patch-g bug report
Cc: cad@ARL.MIL
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: wm@ARL.MIL

<p>
Ken,

<p>
I have added the support for plate mode wedges as described below in patch-g.

<p>
&gt; 2.   'inside' solids were NOT generated and subtracted for 'plate' mode
&gt;       wedges.  Inside solids were generated/subtracted for all OTHER plate
&gt;       mode objects.
&gt;
This should cover your bug report for the patch-g convertor. We should make
arrangements to get the updated source or executable to you.

<p>

<p>
				-Bill

<p>
--
Bill Mermagen Jr.
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa02705; 28 Aug 96 9:43 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa13565; 28 Aug 96 8:55 EDT
Received: from smokey.arl.mil by WALRUS.ARL.MIL id aa13456; 28 Aug 96 8:46 EDT
Date:     Wed, 28 Aug 96 8:45:26 EDT
From:     Bob Parker &lt;bparker@ARL.MIL&gt;
To:       urbanowi@vs.lmco.com
cc:       cad@ARL.MIL
Subject:  Re: Use of "area" in xmged
Message-ID:  &lt;9608280845.aa28486@SMOKEY.ARL.MIL&gt;

<p>

<p>
James Urbanowicz wrote:
&gt;I'm having problems with the "area" command in xmged. When I "E"  an object,
&gt;then try to use "area" on it, all that is displayed is a line that says
&gt;something about area, but there is no output value displayed.  Any ideas?

<p>
You've uncovered a bug. The output is going to stdout via another
process (i.e. cad_parea) instead of being captured and stuffed into
XMGED's command window. For now, you can look in the window
in which XMGED was started to see the return value.

<p>
-Bob
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa29869; 29 Aug 96 8:38 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa28174; 29 Aug 96 3:07 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa28141; 29 Aug 96 3:00 EDT
Date:     Thu, 29 Aug 96 2:50:32 EDT
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       CAD@ARL.MIL
Subject:  LIBRT booleans: more bu_ptbl's
Message-ID:  &lt;9608290250.aa08984@vm.arl.mil&gt;

<p>

<p>
This evening I converted the last of the old-style bit-vectors in
raytrace.h over to a bu_ptbl variable-length pointer array. This
affected the pt_solhits field in the partition structure; it's new name
is pt_solids_hit, and it is now a bu_ptbl.

<p>
This means that when rt_boolfinal() needs to evaluate the boolean trees
for the regions containing the solids found in each partition, rather
than having to scan a bit vector of length "nsolids" for non-zero bits,
it can just read the elements of a compact array.  For models with more
than about 80 solids this should be much faster.  I don't have any time
comparisons yet, because my development version is compiled -g (full
debug, no optimization) while the 4.4 version is compiled -O
(optimized), and that makes a big difference in runtime.

<p>
This change, combined with yesterday's work to eliminate the bit vectors
from the soltab and region structures, the overall memory (RAM)
consumption of LIBRT should be reduced, especially on larger models. To
test this theory, I compared memory use on the benchmark run of the M35
truck.  This database is very small, having 1126 solids in 893 regions.

<p>
Stage		(VAX Ref)	Release 4.4	Development	Savings
<hr>
initial		 907472		 262144		 262144		      0
GETTREE		1352576		1048576		1179648		-131072
PREP		 658960		 393216		 262144		 131072
SHOT		  41752		 655360		 524288		 131072
<hr>
Total		2960760		2359296		2228224		 131072

<p>

<p>
The column marked "VAX Ref" is from the "pix" directory in Release 4.4,
but it looks like it may actually represent Release 4.0 memory use.
The pattern of "savings" between the development and 4.4 versions looks
like it might be an artifact of the system malloc() routine obtaining
memory from UNIX in bigish chunks, perhaps 128Kbytes at a gulp. I
find the 6% savings of 128Kbytes to be of value, although I had hoped
for something more dramatic.  For models 50 times larger the savings
should be substantial.

<p>
The 25% reduction in size over the old "VAX Ref" run shows that we
continue to travel in the proper direction!

<p>
	Best,
	 -Mike
<hr>
<hr>
Date:     Wed, 28 Aug 96 22:14:30 EDT
From:     Mike Muuss  &lt;mike@arl.mil&gt;
To:       ACST@arl.mil
Subject:  RT -J2
Message-ID:  &lt;9608282214.aa08703@vm.arl.mil&gt;

<p>

<p>
I've made the effects of the -J2 flags much more subtle, with the
amplitude reduced in half, from +/- 1/2 pixel width to +/- 1/4 pixel
width, and with period lengthened from 2 seconds to 10 seconds.

<p>
I'd be curious to see a "stationary camera" sequence calculated
with this new code.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa23294; 28 Aug 96 7:52 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa11192; 28 Aug 96 6:24 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa11190; 28 Aug 96 6:17 EDT
Date:     Wed, 28 Aug 96 6:11:20 EDT
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       CAD@ARL.MIL
Subject:  More LIBBU news
Message-ID:  &lt;9608280611.aa08337@vm.arl.mil&gt;

<p>

<p>
This evening I've moved two more sets of fundamental data-structure
support routines into LIBBU:  a nicely generalized version of the
variable-length bit-vector routines from LIBRT, and a slightly improved
version of that workhorse variable-length pointer-table-array routine:
nmg_tbl() from the NMG library.

<p>
Delving into how rt_shootray() and rt_boolfinal() use bit vectors,
I discovered that with the new bu_ptbl() at my disposal, I was able
to make the partition boolean code *much* more efficient, particularly
when large numbers of regions are involved.  Code that had been
O(nsolids)*O(nregions) became O(nsolids)*O(7) in runtime, and I think
I see a way to make that still faster, to roughly O(7)*O(7).

<p>
Having the bu_ptbl() routines handy, I was also able to plug a "memory
leak", regarding the "union cutter" structures not being properly freed
from frame to frame in an animation.  The problem had been that they
were "bulk allocated" and diced up, after which time it was impossible
to tell which items on the freelist corresponded to the head of the
blocks (and thus should be handed to bu_free()), and which ones were
"interior" to the blocks and should just be ignored.  With the new
routines handy, it was a simple matter to just collect a table of the
things to be freed using bu_ptbl_ins(), and then free up all the items
in the table at the proper moment.

<p>
Having power-tools like variable-length-strings and variable-length
pointer arrays makes life so much simpler!

<p>
	Onwards!
	 -Mike
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa27069; 3 Sep 96 20:56 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa26678; 3 Sep 96 20:07 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa26654; 3 Sep 96 19:58 EDT
Date:     Tue, 3 Sep 96 19:58:24 EDT
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       Paul DiCaprio &lt;pauld@kmrmail.kmr.ll.mit.edu&gt;
cc:       CAD@ARL.MIL
Subject:  Re: BRLCAD 4.4 build on IRIX 6.2 R8000 -- Progress (fwd)
Message-ID:  &lt;9609031958.aa22714@wolf.arl.mil&gt;

<p>

<p>
Paul of MIT asked -

<p>
&gt; is RT automatically dividing between both processors in the benchmark?

<p>
By default, RT will use all the processors installed in the machine.
It prints a message letting you know about this, right at the beginning.
Here is an example:

<p>
BRL-CAD Release 4.5   Ray-Tracer
    Sat Aug 31 07:40:28 EDT 1996, Compilation 1691
    mike@vapor.arl.mil:/m/cad/.rt.6d
Planning to run with 24 processors			&lt;&lt;&lt;&lt;&lt;----------
db title:  Gary Moss's "World on a Platter"

<p>
So if your machine has 2 CPUs installed, the default benchmark would use
both CPUs.  You can specify the -P flag to RT to select a different
number of processors, a negative number indicates to use "all but" that
many processors.  For example, -P -4 on a 24-processor machine would
indicate using 20 processors.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa27568; 4 Sep 96 11:48 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id ab10130; 4 Sep 96 11:40 EDT
Received: from wharf.arl.mil by WALRUS.ARL.MIL id aa10013; 4 Sep 96 11:33 EDT
Received: from teas.eglin.af.mil by wharf.arl.mil id aa27814; 4 Sep 96 11:33 EDT
Return-Path: bruennin@teas.eglin.af.mil
Received: by teas.eglin.af.mil (UCX V2.0-22)
	Wed, 4 Sep 1996 10:26:13 -0500
Comments: Authenticated sender is &lt;bruennin@teas.eglin.af.mil&gt;
From:          Bud Bruenning &lt;bruennin@ARL.MIL&gt;
To:            cad@ARL.MIL
Date:          Wed, 4 Sep 1996 10:40:32 +0000
Subject:       BRL-CAD and IRIX 6.2
Return-receipt-to: "Bud Bruenning" &lt;bruennin&gt;
Priority: normal
X-mailer: Pegasus Mail for Windows (v2.01)
Message-ID:  &lt;9609041133.aa27814@wharf.arl.mil&gt;

<p>
This is probably so obvious to most it doesn't need to be said, but I
may not be as swift as some others and maybe there are some others
like me.

<p>
While waiting for the new release that will work on IRIX 6.2, I
simply copied the binaries and other files in  my /usr/brlcad
directory (and sub directories) from my SGI Personal IRIS 4D35
running IRIX 5.3 to a tar tape and moved them  to my new Indigo 2, Impact
10000 running IRIX 6.2 and all that I've used so far (except patch-g)
work quite nicely.  As a matter of fact, some utilities like fb-pix
that complained of a "sgi_getmem" error on my PI don't pesent such
errors on the new Indy.  (Perhaps the old PI is starting to wear
out.)  Anyway, for those who need a SIMPLE SOLUTION and DO NOT NEED
TO COMPILE new code, this seems to work.

<p>

<p>

<p>
Bud Bruenning
    VOICE: (904) 729-6497
      FAX: (904) 729-6400
    214 Government Street, Niceville, FL 32578
e-mail:  bruennin@eglin.af.mil (official business)
         bruennin@gnt.net      (personal-unofficial)
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa23415; 5 Sep 96 22:47 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa12445; 5 Sep 96 21:46 EDT
Received: from wharf.arl.mil by WALRUS.ARL.MIL id aa12416; 5 Sep 96 21:37 EDT
Received: from cleese.nas.com by wharf.arl.mil id aa22123; 5 Sep 96 21:36 EDT
Received: from deliverator(really [198.182.208.46]) by cleese.nas.com
	via sendmail with smtp
	id &lt;m0uypoa-000CzzC@cleese.nas.com&gt;
	for &lt;cad@arl.army.mil&gt;; Thu, 5 Sep 1996 18:34:36 -0700 (PDT)
	(Smail-3.2 1996-Jul-4 #3 built 1996-Jul-12)
Message-Id: &lt;2.2.32.19960906013059.002ff778@cleese.nas.com&gt;
X-Sender: gary@cleese.nas.com (Unverified)
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 05 Sep 1996 18:30:59 -0700
To: MHGETMAN@concentric.net, okie@nwidt.com,
    kcheng@jupiter.risc.rockwell.com, Randys9932@aol.com, CBoth@earthlink.net,
    cindy.liebeck@vlsi.com, bobt@vnet.ibm.com, kmorimo@ebina.hitachi.co.jp,
    VincentHuang@acer.com.tw, shkoh@jupiter.info.samsung.co.kr,
    shaw@scf-fs.usc.edu, mukherje@cup.hp.com, soosoo@hitel.kol.co.kr,
    hhwu@alpha.ee.ufl.edu, 100015.1632@compuserve.com,
    rurban@sbox.tu-graz.ac.at, dennis.shinn@saug.wa.com, josgood@frame.com,
    wammack@aps.anl.gov, joel_orr@mcimail.com, 169932@hdo.com,
    cecilia@hndol.com, 171403@hdo.com, marks@hndol.com,
    webmaster@ic.eecs.berkeley.edu, Rudy@finelinemicro.com,
    Mik.Ferran@cern.ch, pmfdj@crnvma.cern.ch, Nils.Hoimyr@cern.ch,
    f.vanslooten@wb.utwente.nl, rodmur@ecst.csuchico.edu, cad@ARL.MIL,
    jules@cs.man.ac.uk, webmaster@igsrsparc2.er.usgs.gov,
    bob@soest.hawaii.edu, kroenke@soest.hawaii.edu,
    brown@diego.cecer.army.mil, plewe@acsu.buffalo.edu
From: "Gary B. Rohrabaugh" &lt;gary@softsource.com&gt;
Subject: Supporting AutoCAD and DXF drawings on your WEB site

<p>
Here is the information you need to enable your Web site (server)
to allow viewing of AutoCAD or DXF drawings online with industry
standard Netscape & Internet Explorer plug-ins.

<p>
MIME Types

<p>
MIME types are how the Internet applications know what type a file is
This is similar to associating an application with a file on a
Macintosh or associating a program with a file extension under Windows.
In order for browsers to recognize AutoCAD drawing and DXF files so
the appropriate action can take place (e.g. for the proper plug-in to
be run in Netscape), the server needs to have a MIME type associated
with the proper files. Contact your system administrator for more
information on how to do this.

<p>
                    extensions    Official MIME types

<p>
AutoCAD drawing    .DWG or .dwg    image/vnd.dwg

<p>
DXF                .DXF or .dxf    image/vnd.dxf

<p>

<p>
NOTE: On April 4, 1996 the IANA (Internet Assigned Numbers Authority)
officially registered the following new Media Types, content-type/subtype
pairs to SoftSource: image/vnd.dwg, and image/vnd.dxf.

<p>
After adding MIME types, your server may need to be restarted.
Additionally, Netscape may have cached any images and associated MIME
types you have previously viewed, so you may need to clean out the local
cache before retrying images.

<p>
See the FAQ in the SoftSource Files plugin page for Optional Tags
settings to control display of AutoCAD and DXF drawings at your site.

<p>
http://www.softsource.com/plugins/faq.html
http://www.softsource.com

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa21668; 13 Sep 96 16:21 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa09322; 13 Sep 96 15:10 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa09288; 13 Sep 96 15:06 EDT
Received: from localhost by wolf.arl.mil id aa16975; 13 Sep 96 15:00 EDT
Date: Fri, 13 Sep 1996 15:00:49 -0400 (EDT)
From: "Lee A. Butler" &lt;butler@ARL.MIL&gt;
To: "Daniel J. Rinald" &lt;rinald@ngic.osis.gov&gt;
cc: cad@brl.mil
Subject: Re: rt
In-Reply-To: &lt;9609131130.AA12183@spock.ngic.osis.gov&gt;
Message-ID: &lt;Pine.SGI.3.95.960913145645.16480A-100000@wolf.arl.mil&gt;
X-URL: http://ftp.arl.mil/~butler/
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

<p>
On Fri, 13 Sep 1996, Daniel J. Rinald wrote:

<p>
&gt; 1. What is the current status on an mged to vrml(inventor) translator?

<p>
Look at "http://ftp.arl.mil/~jra/" and you will find that John Anderson has
done some work in this area.  Alas, VRML and BRL-CAD use radically different
modeling constructs.  It is therefore not always possible to build an
elegant VRML representation of a BRL-CAD object.  I suspect John's converter
will be in the next release.

<p>
&gt; 2. I wish to have an emissive target, i.e., no shiny reflections from ambient
&gt; lighting. Is this possible? I have tried setting material properties to
&gt; plastic, diffuse -&gt; 1.0, reflect -&gt; 0.0, and the rt ambient light option
&gt; A -&gt; 0, but I still seem to get a strong reflective light back from
&gt; perpendicular facets to the eye. I even tried using "rt -l 1". Any thoughts?

<p>
Look at the "light" shader.  It does essentially what you seek.

<p>
Lee

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa29203; 13 Sep 96 9:59 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa00836; 13 Sep 96 9:58 EDT
Received: from wharf.arl.mil by WALRUS.ARL.MIL id aa00830; 13 Sep 96 9:55 EDT
Received: from survice.com by wharf.arl.mil id aa10879; 13 Sep 96 9:55 EDT
Received: from 206.181.114.201 by fudge.survice.com via SMTP (940816.SGI.8.6.9/940406.SGI)
	 id JAA12308; Fri, 13 Sep 1996 09:55:39 -0400
Message-ID: &lt;32396884.6F03@survice.com&gt;
Date: Fri, 13 Sep 1996 09:58:31 -0400
From: Bob Strausser &lt;bobs@survice.com&gt;
Organization: The SURVICE Engineering Co. / SURVIAC ASO
X-Mailer: Mozilla 3.0 (Macintosh; I; PPC)
MIME-Version: 1.0
To: "Daniel J. Rinald" &lt;rinald@ngic.osis.gov&gt;, cad@ARL.MIL
Subject: RT without the bright spot
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

<p>
Daniel,

<p>
Concerning, the raytracing problem.  The only way I know of getting rid
of the eyepoint bright spot is to put your own light into the model.
This of course creates a bright spot relative to the position of your
light and its color.

<p>
I placed a sphere in a sample geometry, used the mater command to assign
the material "light" and a color of black (0 0 0).  I placed it below my
geometry objects in the display and raytraced the view with ambient
lighting set to 100%.  This gave a very nice flat image without any
bright spots from any light sources.

<p>
Without setting the color to black and setting ambient lighting to 0%
gave a very nice halo effect image.  A similar halo occurs with the
default level of ambient lighting.  Setting ambient lighting to 100%
once again gives a nice non-spotlighted image.  The black light source
with zero ambient lighting gives a completely black image of course.

<p>
Bob Strausser
SURVIAC ASO
<hr>
<hr>
Received: from admii.arl.mil by wolf.arl.mil id aa12010; 22 Sep 96 0:33 EDT
Received: from ms.ha.md.us by ADMII.ARL.MIL id aa29216; 22 Sep 96 0:16 EDT
Received: from hawks.ha.md.us by ms.ms.ha.md.us id aa09761; 21 Sep 96 23:27 EDT
Received: (from butler@localhost) by hawks.ha.md.us (8.7.4/8.7.3) id XAA20179; Sat, 21 Sep 1996 23:27:10 -0400 (EDT)
Date: Sat, 21 Sep 1996 23:27:09 -0400 (EDT)
From: Lee Butler &lt;butler@hawks.ha.md.us&gt;
To: bsdi-users@bsdi.com
Subject: CPU Performance: Cyrix vs. Intel
Message-ID: &lt;Pine.BSI.3.91.960921224647.20110A-100000@hawks.ha.md.us&gt;
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Date:  Sun, 22 Sep 96 0:12:11 EDT
Resent-From:  	 Mike Muuss &lt;mike@ms.ha.md.us&gt;
Resent-To:  mike@ARL.MIL

<p>
I've recently had both the CyrixP166+ and the Intel Pentium166 in a Tyan
Tomcat motherboard.  I thought I'd pass on what I've learned to the list.

<p>
First of all, both parts performed flawlessly.  I had no unexpected reboots
or hangs.

<p>
The short of it is this:

<p>
Code			Cyrix	Intel
--------------------------------------
Boot Delay Multiplier	5644	4244
RT Benchmark		  26	  43

<p>
Price (US$)		 273	 427

<p>

<p>
In both benchmarks a bigger number indicates faster operation.

<p>
The "Boot Delay Multiplier" calculation is an entirely integer process.  Here
the speed advantage of the Cyrix chip is clear.  The speculative execution
and/or branch prediction hardware pays off big.  This is especially true
since the Cyrix chip is running at 133Mhz internally, instead of 166Mhz.

<p>
The "RT Benchmark" is a raytracing application and does a relatively large
amount of floating point operations in addition to some complex coding
structures.  While the Cyrix chip does well at optimizing the branching and
looping conditions, the floating point unit just isn't a match for the Intel
part.  Floating point performance on the 133Mhz Cyrix is roughly equal to
a Pentium90.

<p>
Certainly if you are running an ISP and just serving web pages and running
E-mail boxes, I'd seriously consider the Cyrix part.  Better, faster,
cheaper for that type of application.  It's also a bit faster at typical GUI
painting for X-workstations (mostly integer bit shuffling).

<p>
There are two things that recommend the Intel part.  The first is if you do
more than a little floating point computation.  If you're doing anything
like scientific computing, I'd go with the Intel chip.

<p>
The second is if you want to run multiple CPU's on one motherboard.
While Cyrix cpu's can support multi-processor motherboards, they use a
different standard than the (proprietary) one that Intel uses.  I've heard
that dual CPU motherboards will soon be available for the Cyrix chips, but
they don't seem to be out there today.

<p>
Lee Butler	butler@hawks.ha.md.us

<p>
As nightfall does not come at once, neither does oppression.  In both
instances, there is a twilight when everything remains seemingly unchanged.
And it is in such twilight that we all must be most aware of change in the
air--however slight--lest we become unwitting victims of the darkness.
--- Justice William O. Douglas
<hr>
<hr>
Received: from localhost by wolf.arl.mil id aa14780; 24 Sep 96 9:10 EDT
Date: Tue, 24 Sep 1996 09:10:51 -0400 (EDT)
From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" &lt;jra@arl.mil&gt;
To: "Fredrick V. Heitkamp" &lt;heitkafv@aa.wpafb.af.mil&gt;
cc: Mike Muuss &lt;mike@ARL.MIL&gt;, jra@arl
Subject: Re: BRL CAD Raytracer Question
In-Reply-To: &lt;960923092855.20793@ethel.aa.wpafb.af.mil.0&gt;
Message-ID: &lt;Pine.SGI.3.95.960924090500.13728A-100000@wolf.arl.mil&gt;
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

<p>
On Mon, 23 Sep 1996, Fredrick V. Heitkamp wrote:

<p>
&gt; Mike,
&gt;
&gt; Thanks for the reply.  I have yet another question.  Is there a way presently,
&gt; to
&gt; convert IGES 114 to BRL-CAD?

<p>
	No, the IGES 114 is a parametric spline surface, and we haven't
done any support for that yet. You may be able to find some software to
convert the 114 entities to 128 entities (NURBS) which we can import
from IGES. Check at http://www.eeel.nist.gov/iges/igesTools.htm. They
have some free tools available there.

<p>

<p>
			-John

<p>
&gt; Fred Heitkamp
&gt; WL/AAJS (formerly WL/AARI-1)
&gt; WPAFB OH
&gt; 513 255 5922 x271
&gt;
&gt; &gt;
&gt; &gt;The BRL-CAD ray-tracer is rather nice.
&gt; &gt;
&gt; &gt;We have a BRL-CAD to ACAD geometry converter.  I know that a flat-facet
&gt; &gt;ACAD to BRL-CAD converter is "in the works", I don't know if it's done
&gt; &gt;yet or not.  It's a small project, about 10 pages of code.
&gt; &gt;
&gt; &gt;	Best,
&gt; &gt;	 -Mike Muuss
&gt; &gt;
&gt; &gt;	  Senior Computer Scientist
&gt; &gt;	  Ballistic Vulnerability/Lethality Division
&gt; &gt;	  Survivability and Lethality Analysis Directorate
&gt; &gt;	  The U.S. Army Research Laboratory
&gt; &gt;	  Attn: AMSRL-SL-BV
&gt; &gt;	  APG, MD  21005-5068  USA
&gt; &gt;
&gt; &gt;	  My E-mail is &lt;Mike @ ARL.MIL&gt;
&gt; &gt;	  My World-Wide-Web URL is http://ftp.arl.mil/~mike/
&gt; &gt;
&gt; &gt;	  410-278-6678 Voice
&gt; &gt;	  410-278-6656 Secretary
&gt; &gt;	  410-278-5058 FAX
&gt;

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058

<p>
AMC says that my views do not represent an official Government position.

<p>
<hr>
<hr>
Received: from vapor.arl.mil by wolf.arl.mil id aa28218; 27 Sep 96 4:34 EDT
Date:     Fri, 27 Sep 96 4:34:53 EDT
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       ACST@ARL.MIL
cc:       wbowman@ARL.MIL, gillis@ARL.MIL, reed@ARL.MIL,
          CJohnson@camelot.com
Subject:  h/sed4
Message-ID:  &lt;9609270434.aa24265@VAPOR.ARL.MIL&gt;

<p>

<p>
I've created a file in h/sed4 which you can use to feed to ED to mostly
automatically convert a C source file written for Release 4.4 to the new
bu.h and bn.h routines for Release 5.0.

<p>
I've run it on the NMG code in LIBRT, it required minimal hand-tweeking
afterward.

<p>
	Best,
	 -Mike
<hr>
<hr>
Date:     Sat, 28 Sep 96 19:32:04 EDT
From:     Mike Muuss  &lt;mike@arl.mil&gt;
To:       Mike Muuss &lt;mike@arl.mil&gt;
cc:       ACST@ARL.MIL, wbowman@ARL.MIL, gillis@ARL.MIL, reed@ARL.MIL,
           CJohnson@camelot.com
Subject:  Re: h/sed4
Message-ID:  &lt;9609281932.aa27413@wolf.arl.mil&gt;

<p>

<p>
Just to clarify:  It is NOT necessary to apply h/sed4 to C source in
order to get it to work with Release 5.0; the h/compat4.h header file
is auto-included by raytrace.h, and provides 100% source compatability.

<p>
It just seemed appropriate to me that the libraries be internally
converted, rather than relying on h/compat4.h.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa19515; 15 Oct 96 11:07 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa09314; 15 Oct 96 9:37 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa09230; 15 Oct 96 9:22 EDT
Received: from localhost by wolf.arl.mil id aa12737; 15 Oct 96 9:08 EDT
Date: Tue, 15 Oct 1996 09:08:15 -0400 (EDT)
From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" &lt;jra@ARL.MIL&gt;
To: eorddyo@techunix.technion.ac.il
cc: CAD@ARL.MIL
Subject: Re: Xmged help
In-Reply-To: &lt;Chameleon.4.01.961014120122.Yoav@Yoav Oreg.technion.ac.il&gt;
Message-ID: &lt;Pine.SGI.3.95.961015090531.11568B-100000@wolf.arl.mil&gt;
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

<p>
On Mon, 14 Oct 1996 eorddyo@techunix.technion.ac.il wrote:

<p>
&gt; Hello all,
&gt; I have some problems doing some things in Xmged I hope you will help me with,I am stuck in the
&gt; middle of a big project so fast replies will be greatly appreciated.
&gt;
&gt; 1)"rotobj" rotates an object a specified angle around the objects key point.I need to rotate an
&gt; objectaround a point of my choice, I thought "qorot" will do it but it doesn't  seems to rotate
&gt; the object the way I wish. I may be doing something wrong???

<p>
	"Qrot" allows you to rotate an object about an arbitrary axis.
The regular "rotobj" rotates about the "X", "Y", or "Z" axes only.

<p>
&gt; 2)is it possible to redefine an obejct's key point?

<p>

<p>
	Yes, see the "keypoint" command"

<p>

<p>
			-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058

<p>
AMC says that my views do not represent an official Government position.

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa04942; 23 Oct 96 23:32 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa20557; 23 Oct 96 22:53 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa20554; 23 Oct 96 22:47 EDT
Date:     Wed, 23 Oct 96 22:41:35 EDT
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       "Richard S Sandmeyer { Chief, VMB-BVLD-SLAD-ARL }" &lt;richsand@ARL.MIL&gt;
cc:       Cad@ARL.MIL
Subject:  rt_comb_v4_export
Message-ID:  &lt;9610232241.aa01870@wolf.arl.mil&gt;

<p>

<p>
Hi Rich -

<p>
&gt;      OK, I'll bite.  What are v4/v5 (version numbers)?  You've
&gt; got so many BRL-CAD irons in the fire that I'm not sure to which
&gt; new capability this message refers.

<p>
Oops, yes, that's likely to be confusing without context.  Here I'm
referring to the geometry database format. v1, v2, and v3 were the
original ".g" (aka ".vg") formats for GED (pre MGED, pre BRL-CAD), v4 has
been the production ".g" format for BRL-CAD since 1985, v5 is the fabled
"new database" format that we've been talking about for the past year or
so.

<p>
I realize these numbers are confusing, as there is also BRL-CAD Release
4.4 (production and 5.0 (development), FASTGEN 4 and FASTGEN 5, COMGEOM
4 and COMGEOM 5, SunOS 4 and SunOS 5, etc.etc.  Seems to be "the time"
for 4 and 5 as version numbers in mature products. *grin*

<p>
Anyway, the progress report was just to let you know that important pieces
of the v5 database are beginning to solidify into actual working C code,
rather than just being specifications on a Web page.

<p>
http://ftp.arl.mil/~mike/papers/brlcad5.0/newdb.html  for the specs.  :-)

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa12855; 4 Nov 96 9:56 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa19902; 4 Nov 96 8:37 EST
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa19840; 4 Nov 96 8:29 EST
Received: from localhost by wolf.arl.mil id aa07841; 4 Nov 96 8:24 EST
Date: Mon, 4 Nov 1996 08:24:37 -0500 (EST)
From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" &lt;jra@ARL.MIL&gt;
To: "ndaglis@acs.itd.uts.edu.au" &lt;ndaglis@acs.itd.uts.edu.au&gt;
cc: CAD@ARL.MIL
Subject: Re: newbie needs help.
In-Reply-To: &lt;199611040512.QAA24513@acacia.itd.uts.edu.au&gt;
Message-ID: &lt;Pine.SGI.3.95.961104082222.7364A-100000@wolf.arl.mil&gt;
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

<p>
On Mon, 4 Nov 1996, ndaglis@acs.itd.uts.edu.au wrote:

<p>
&gt; Hi,
&gt; 	I've gotten brlcad to compile on my Linux box, and subsequently
&gt; hit a solid wall at every turn. My configuration is:
&gt;
&gt; 	Linux kernel 2.(something)
&gt; 	Motif 2.0
&gt; 	X11 R6 - xfree3.1.2
&gt;
&gt; The biggest problem I think I have is that when I do
&gt; 	xmged world.g all
&gt;
&gt; I get an error about the world.g file not being in the right form -
&gt; it says its lacking the header or something.
&gt;
&gt; Also xmged dumps core straight after it gives this error.
&gt;
&gt;
&gt; I'm that new to this that I don't now what it is I don't know about
&gt; getting this to work.
&gt;
&gt; Perhaps someone could direct me to a modern compiled version of
&gt; brlcad for linux. ie ELF, recent C libs, X11R6 etc.
&gt;
&gt; thanks ndaglis@acs.itd.uts.edu.au
&gt;

<p>

<p>
Here is a message I posted to "cad" earlier this year:

<p>

<p>
From jra@ARL.milMon Aug 12 14:50:57 1996
Date: Wed, 5 Jun 1996 08:27:43 -0400 (EDT)
From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" &lt;jra@ARL.mil&gt;
To: Dwight M Evers &lt;evers@plains.nodak.edu&gt;
Cc: cad@ARL.mil
Subject: Re: [Q] Who has installed BRL on a linux box???

<p>
On 4 Jun 1996, Dwight M Evers wrote:

<p>
&gt; Could someone give some helpful hints on installing brl-cad R4.4 on a
&gt; linux box???
&gt;
&gt; -TIA
&gt;
&gt; ============================================================================
&gt; 			|	"...peace is a thing which a person
&gt; Dwight M. Evers		|	    must be willing to fight for..."
&gt; evers@plains.NoDak.edu	|
&gt; 	NDSU		|			-Abe Lincoln
&gt; ============================================================================
&gt;
---------- Forwarded message ----------
Date: Thu, 28 Dec 1995 12:10:13 -0500 (EST)
From: John R. Anderson (USARL/SLAD/BVLD/VMB) &lt;jra@arl.mil&gt;
To: ged@walrus.arl.mil
Subject: BRL-CAD 4.4 under Linux 1.2.8

<p>

<p>
	I finally got around to installing BRL-CAD 4.4 on my PC. I am
running Linux 1.2.8 on a Packard Bell with a Pentium 75 Mhz Processor
and 16Mb of memory. My compiler is gcc version 2.6.3. I needed to make a
few changes to get BRL-CAD compiled, here they are:

<p>
1. The makefile for cake ("cake/Makefile") calls lex to process
"cake_s.l". There are some ifdefs in "cake_s.l"  to account for the fact
that "flex" (the GNU version of lex) does not define "yylineno".
However, under this version of Linux, "lex" is defined as "flex -l". The
"-l" option to "flex" tells it to be compatible with the orignal AT&T
"lex". The result of all this is that the ifdefs are trying to correct
for differences that aren't there. The easy fix here is to replace "lex"
in the cake "Makefile" with "flex".

<p>
2. In libplot3, version 2.6.3 of gcc cannot compile plot3.c with the
default O2 optimization. This has been reported to MIT as a compiler
bug. The fix is to compile plot3.c with no optimization or use GCC
version 2.7.2.

<p>

<p>
3. After compilation, "mged" worked fine, but "rt" complained: "db_scan
ERROR:  File is lacking a proper MGED database header". I'm not yet sure
of the basic problem behind this, but it has to do with opening a file
twice (once to get a file descriptor and once to get a FILE pointer).
In "librt/db_open.c" there is a block of code :

<p>
                if( !dbip-&gt;dbi_inmem && sb.st_size &lt;= INMEM_LIM )  {
                        dbip-&gt;dbi_inmem = rt_malloc( sb.st_size,
                                "in-memory database" );
                        if( read( dbip-&gt;dbi_fd, dbip-&gt;dbi_inmem,
                            sb.st_size ) != sb.st_size )
                                goto fail;
                        if(rt_g.debug&DEBUG_DB)
                                rt_log("db_open: in-memory file\n");
                }

<p>
This reads the entire database file into memory if it is small enough.
Later "db_scan" rewinds the database file and looks for the "proper MGED
database header" using "fread" (note that "db_open" used "read") .
It appears that under Linux 1.2.8 there is some missing communication
between the file descriptor and the FILE pointer. The "fread" call in
"db_scan" returns "0" and "foef" returns true. This means that even
though the file was just rewound, it is still at EOF. The fix for this
one is to just replace

<p>
                        if( read( dbip-&gt;dbi_fd, dbip-&gt;dbi_inmem,
                            sb.st_size ) != sb.st_size )
in "db_open.c" with

<p>
                        if( fread( dbip-&gt;dbi_inmem, sb.st_size,
			    1, dbip-&gt;dbi_fp ) != 1 )

<p>

<p>

<p>
With this last change, "rt" now works. I ran the benchmark and got the following:

<p>
Abs	4021.12	1963.12	1752.41	1630.53	1995.19	2272.47	Thu Dec 28 01:41:28 EST 1995
*vgr	29.34	29.27	31.25	30.55	28.22	29.72

<p>

<p>
Not bad for 75 Mhz Pentium!!!
(I verified a couple of the timings by hand)

<p>
---------- Forwarded message ----------
Date: Wed, 14 Feb 1996 09:22:45 -0500 (EST)
From: John R. Anderson (USARL/SLAD/BVLD/VMB) &lt;jra@arl.mil&gt;
To: "Thomas M. Browder Jr." &lt;browder@eglin.af.mil&gt;
Cc: cad@ARL.MIL
Subject: Re: Linux version of BRL-CAD (mged)

<p>
On Tue, 13 Feb 1996, Thomas M. Browder Jr. wrote:

<p>
&gt; we have a working installation of Linux BRL-CAD, and everything seems
&gt; to be working (or at least usable) except one thing:
&gt;
&gt;   in mged, the concat command finds an error with the model data base
&gt;   one is trying to concatenate
&gt;
&gt;   the model data base checks out ok independently, and it can be opened
&gt;   with dbopen, it just cannot be merged inside the primary model
&gt;
&gt; the actual lines from a session are as follows:
&gt;
&gt;   mged&gt; concat model.g
&gt;   concat: Enter prefix string or / for no prefix: /
&gt;   db_read(model.g) ERROR offset=128, count=128, dbi_eof=-1
&gt;   Database read error, aborting
&gt;   mged&gt;
&gt;
&gt; Any help would be appreciated.
&gt;
&gt; Tom Browder
&gt; ASI Systems International

<p>
	I suspect the problem is one I mentioned in a message I posted
when I first installed BRL-CAD on my Linux system:

<p>

<p>
-----------------------------
3. After compilation, "mged" worked fine, but "rt" complained: "db_scan
ERROR:  File is lacking a proper MGED database header". I'm not yet sure
of the basic problem behind this, but it has to do with opening a file
twice (once to get a file descriptor and once to get a FILE pointer).
In "librt/db_open.c" there is a block of code :

<p>
                if( !dbip-&gt;dbi_inmem && sb.st_size &lt;= INMEM_LIM )  {
                        dbip-&gt;dbi_inmem = rt_malloc( sb.st_size,
                                "in-memory database" );
                        if( read( dbip-&gt;dbi_fd, dbip-&gt;dbi_inmem,
                            sb.st_size ) != sb.st_size )
                                goto fail;
                        if(rt_g.debug&DEBUG_DB)
                                rt_log("db_open: in-memory file\n");
                }

<p>
This reads the entire database file into memory if it is small enough.
Later "db_scan" rewinds the database file and looks for the "proper MGED
database header" using "fread" (note that "db_open" used "read") .
It appears that under Linux 1.2.8 there is some missing communication
between the file descriptor and the FILE pointer. The "fread" call in
"db_scan" returns "0" and "foef" returns true. This means that even
though the file was just rewound, it is still at EOF. The fix for this
one is to just replace

<p>
                        if( read( dbip-&gt;dbi_fd, dbip-&gt;dbi_inmem,
                            sb.st_size ) != sb.st_size )
in "db_open.c" with

<p>
                        if( fread( dbip-&gt;dbi_inmem, sb.st_size,
                            1, dbip-&gt;dbi_fp ) != 1 )
-----------------------------

<p>

<p>
	Looking at the code just now, I notice that this block of code
seems to be missing a line setting the value of "dbip-&gt;dbi_eof". This
could be the cause of the error. I would try adding a "dbip-&gt;dbi_eof =sb.st_size;"
in the same block of code discussed above as shown:

<p>
                if( !dbip-&gt;dbi_inmem && sb.st_size &lt;= INMEM_LIM )  {
                        dbip-&gt;dbi_inmem = rt_malloc( sb.st_size,
                                "in-memory database" );
                        if( read( dbip-&gt;dbi_fd, dbip-&gt;dbi_inmem,
                            sb.st_size ) != sb.st_size )
                                goto fail;
			dbip-&gt;dbi_eof = sb.st_size;
                        if(rt_g.debug&DEBUG_DB)
                                rt_log("db_open: in-memory file\n");
                }

<p>

<p>

<p>
			-John

<p>

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058

<p>
AMC says that my views do not represent an official Government position.

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa27477; 21 Jan 97 10:32 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa00118; 21 Jan 97 9:02 EST
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa00077; 21 Jan 97 8:44 EST
Received: from localhost by wolf.arl.mil id aa20174; 21 Jan 97 8:32 EST
Date: Tue, 21 Jan 1997 08:32:49 -0500 (EST)
From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" &lt;jra@ARL.MIL&gt;
To: eorddyo@techunix.technion.ac.il
cc: cad@ARL.MIL
Subject: Re: xmged problems
In-Reply-To: &lt;Chameleon.4.01.970120151330.Yoav@Yoav Oreg.technion.ac.il&gt;
Message-ID: &lt;Pine.SGI.3.95.970121081703.18109A-100000@wolf.arl.mil&gt;
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

<p>

<p>
On Mon, 20 Jan 1997 eorddyo@techunix.technion.ac.il wrote:

<p>
&gt; Hi all,
&gt; I"ve encounterd some problems using xmged:
&gt; after building an object which is a group composed of two regions
&gt; I tried to make a mirror image of it using yjr "mirror" comand. The copy was created, I then
&gt; tried placing it in the right place but when I placed "accept edit" the object I moved jumped to
&gt; it's original location and I got a message sayin the objects could not be reploted.
&gt; I encountered this phenomenon using the "copy" comand as well.
&gt; any sugestions?

<p>
	I tried this myself and couldn't duplicate this behavior. When
the mirror command is applied to a group or region, it does not create a
new copy of the underlying objects. Only the new object mentioned on the
"mirror" command line is created. The new combination (group or region)
references the same underlying objects, but uses transformation matrices
to position them. If you edit the underlying objects, they will change
in both the original and the copy, but the relationship between the
original and the copy will stay the same. What you really want to do is
to use "object edit". The first step in doing an object edit (after
selecting "Object Illum" on the menu) is to pick the object you want to
edit. Move the mouse vertically to highlight different solids from the
objects on the screen until you find the one you want in the object you
want to edit. After you click the mouse to select the object, you will
be in "OBJ PATH" mode. In this mode, you move the mouse vertically to
select which transformation matrix to edit. Place the "[MATRIX]"
directly above the object you want to move. This will typically be the
new object that you created with the mirror command.

<p>
&gt; P.S.
&gt; there may be something wrong with my subscription since I have recieved no mail from cad@ARL.MIL
&gt; since the begining of November, please resubscribe me if nesesary and e-mail me answers directly
&gt; untill I can be sure I"m back on the general mailing list
&gt; thanks Yoav

<p>
	Yes, I removed your old address from the email list after getting
numerous failed mail messages. I have placed your new email address back in
the "cad" list.

<p>

<p>
			-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058

<p>
AMC says that my views do not represent an official Government position.

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa00468; 22 Jan 97 13:05 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa15915; 22 Jan 97 11:08 EST
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa15903; 22 Jan 97 11:03 EST
Received: from localhost by wolf.arl.mil id aa21293; 22 Jan 97 10:51 EST
Date: Wed, 22 Jan 1997 10:51:00 -0500 (EST)
From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" &lt;jra@ARL.MIL&gt;
To: "C. D. Turner" &lt;cdturne@sass206.tpa.sandia.gov&gt;
cc: cad@ARL.MIL
Subject: Re: vdeck
In-Reply-To: &lt;199701211959.MAA02441@sass193.&gt;
Message-ID: &lt;Pine.SGI.3.95.970122104733.20989A-100000@wolf.arl.mil&gt;
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

<p>
On Tue, 21 Jan 1997, C. D. Turner wrote:

<p>
&gt; The included file (created with brlcad 4.4) contains one region, box.r. When I
&gt; attempt to convert to gift using vdeck rev 11.1 (from brlcad 4.4) I get the
&gt; following:
&gt;
&gt; ---------------------------------
&gt; zia% ~/cad/bin/vdeck test.g
&gt;
&gt; command( ? for menu )&gt;&gt; insert box.r
&gt;
&gt; command( ? for menu )&gt;&gt; list
&gt; box.r
&gt;
&gt; command( ? for menu )&gt;&gt; deck
&gt;
&gt; ERROR: bad pointer x39070: s/b union tree(x91191191), was NULL(x0), file
&gt; ../librt/db_tree.c, line 908
&gt; ----------------------------------
&gt;
&gt; When I use the old rev of vdeck, 10.2 (from brlcad 4.0) it works fine.
&gt; Any suggestions?
&gt;
&gt; Thanks,
&gt; David Turner
&gt; SNL/A

<p>
	Yes, a line needs to be added to vdeck.c near the end of the
routine gettree_leaf(). The "magic" number for the curtree structure is
not getting set. The existing code is:

<p>

<p>
        GETUNION( curtree, tree );
        curtree-&gt;tr_op = OP_SOLID;
        curtree-&gt;tr_a.tu_stp = stp;
        curtree-&gt;tr_a.tu_regionp = (struct region *)0;

<p>
        return(curtree);

<p>

<p>
It should be changed to:

<p>
        GETUNION( curtree, tree );
        curtree-&gt;magic = RT_TREE_MAGIC;
        curtree-&gt;tr_op = OP_SOLID;
        curtree-&gt;tr_a.tu_stp = stp;
        curtree-&gt;tr_a.tu_regionp = (struct region *)0;

<p>
        return(curtree);

<p>

<p>

<p>
			-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058

<p>
AMC says that my views do not represent an official Government position.

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa01008; 26 Jan 97 9:44 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa10422; 26 Jan 97 9:41 EST
Received: from admii.arl.mil by WALRUS.ARL.MIL id aa10395; 26 Jan 97 9:31 EST
Received: from relay4.UU.NET by ADMII.ARL.MIL id aa12017; 26 Jan 97 9:09 EST
Received: from news.ziplink.net by relay4.UU.NET with ESMTP
	(peer crosschecked as: news.ziplink.net [199.232.240.5])
	id QQcaea24621; Sun, 26 Jan 1997 09:09:23 -0500 (EST)
Received: (from news@localhost) by news.ziplink.net (8.7.6/8.6.12) id JAA01194; Sun, 26 Jan 1997 09:08:46 -0500 (EST)
To: info-brl-cad@uunet.uu.net
Path: localhost!nobody
From: Craig Earls &lt;NoSpam@my.house&gt;
Newsgroups: info.brl-cad
Subject: BRL-CAD on Linux
Date: 26 Jan 1997 09:01:11 -0500
Organization: MIT/US Navy
Lines: 19
Message-ID: &lt;m0lo9g4jtk.fsf@my.house&gt;
NNTP-Posting-Host: lowell-ip241.ziplink.net
X-Newsreader: Gnus v5.2.25/XEmacs 19.14

<p>

<p>
Does anyone have a patch to compile BRL-CAD under a more recent
release of Linux? The patch available at SUNSITE is from 1995 and
appears to depend on some fairly old versions of libraries. Just
wondering if anyone has already slogged through this, before I start
the trudge:)

<p>
I am running
Linux 2.0.28
libc 5.4.17
libg++2.7.2.1
XFree86 3.2

<p>
Thanks for any assistance

<p>
-----------------------------------------------------------------
Craig P Earls				      cpearls@ziplink.net
LT US Navy, MIT Ocean Engineering	      cpearls@mit.edu
-----------------------------------------------------------------
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa11439; 27 Jan 97 8:16 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa18975; 27 Jan 97 8:13 EST
Received: from whim.arl.mil by WALRUS.ARL.MIL id aa18856; 27 Jan 97 8:04 EST
From: jehunt@ARL.MIL
To: cad@ARL.MIL
In-reply-to: &lt;m0lo9g4jtk.fsf@my.house&gt; (message from Craig Earls on 26 Jan
	1997 09:01:11 -0500)
Subject: Re: BRL-CAD on Linux
Date: Mon, 27 Jan 97 7:57:49 EST
Sender: jehunt@ARL.MIL
Message-ID:  &lt;9701270757.aa22275@whim.arl.mil&gt;
Source-Info:  From (or Sender) name not authenticated.

<p>
&gt; From: Craig Earls &lt;NoSpam@my.house&gt;
&gt; Newsgroups: info.brl-cad
&gt; Date: 26 Jan 1997 09:01:11 -0500

<p>
&gt; Does anyone have a patch to compile BRL-CAD under a more recent
&gt; release of Linux? The patch available at SUNSITE is from 1995 and
&gt; appears to depend on some fairly old versions of libraries. Just
&gt; wondering if anyone has already slogged through this, before I start
&gt; the trudge:)

<p>
Someone should look into getting that old patch off of sunsite.
It is obsolete.  The latest patch for BRLCAD 4.4 comes courtesy of
John Anderson, attached.

<p>
--jim

<p>
---------- Forwarded message ----------
Date: Thu, 28 Dec 1995 12:10:13 -0500 (EST)
From: John R. Anderson (USARL/SLAD/BVLD/VMB) &lt;jra@arl.mil&gt;
To: ged@walrus.arl.mil
Subject: BRL-CAD 4.4 under Linux 1.2.8

<p>

<p>
	I finally got around to installing BRL-CAD 4.4 on my PC. I am
running Linux 1.2.8 on a Packard Bell with a Pentium 75 Mhz Processor
and 16Mb of memory. My compiler is gcc version 2.6.3. I needed to make a
few changes to get BRL-CAD compiled, here they are:

<p>
1. The makefile for cake ("cake/Makefile") calls lex to process
"cake_s.l". There are some ifdefs in "cake_s.l"  to account for the fact
that "flex" (the GNU version of lex) does not define "yylineno".
However, under this version of Linux, "lex" is defined as "flex -l". The
"-l" option to "flex" tells it to be compatible with the orignal AT&T
"lex". The result of all this is that the ifdefs are trying to correct
for differences that aren't there. The easy fix here is to replace "lex"
in the cake "Makefile" with "flex".

<p>
2. In libplot3, version 2.6.3 of gcc cannot compile plot3.c with the
default O2 optimization. This has been reported to MIT as a compiler
bug. The fix is to compile plot3.c with no optimization or use GCC
version 2.7.2.

<p>

<p>
3. After compilation, "mged" worked fine, but "rt" complained: "db_scan
ERROR:  File is lacking a proper MGED database header". I'm not yet sure
of the basic problem behind this, but it has to do with opening a file
twice (once to get a file descriptor and once to get a FILE pointer).
In "librt/db_open.c" there is a block of code :

<p>
                if( !dbip-&gt;dbi_inmem && sb.st_size &lt;= INMEM_LIM )  {
                        dbip-&gt;dbi_inmem = rt_malloc( sb.st_size,
                                "in-memory database" );
                        if( read( dbip-&gt;dbi_fd, dbip-&gt;dbi_inmem,
                            sb.st_size ) != sb.st_size )
                                goto fail;
                        if(rt_g.debug&DEBUG_DB)
                                rt_log("db_open: in-memory file\n");
                }

<p>
This reads the entire database file into memory if it is small enough.
Later "db_scan" rewinds the database file and looks for the "proper MGED
database header" using "fread" (note that "db_open" used "read") .
It appears that under Linux 1.2.8 there is some missing communication
between the file descriptor and the FILE pointer. The "fread" call in
"db_scan" returns "0" and "foef" returns true. This means that even
though the file was just rewound, it is still at EOF. The fix for this
one is to just replace

<p>
                        if( read( dbip-&gt;dbi_fd, dbip-&gt;dbi_inmem,
                            sb.st_size ) != sb.st_size )
in "db_open.c" with

<p>
                        if( fread( dbip-&gt;dbi_inmem, sb.st_size,
			    1, dbip-&gt;dbi_fp ) != 1 )

<p>

<p>

<p>
With this last change, "rt" now works. I ran the benchmark and got the following:

<p>
Abs	4021.12	1963.12	1752.41	1630.53	1995.19	2272.47	Thu Dec 28 01:41:28 EST 1995
*vgr	29.34	29.27	31.25	30.55	28.22	29.72

<p>

<p>
Not bad for 75 Mhz Pentium!!!
(I verified a couple of the timings by hand)

<p>

<p>

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058

<p>
AMC says that my views do not represent an official Government position.

<p>
---------- End forwarded message ----------
<hr>
<hr>
Date:     Fri, 7 Feb 97 11:39:29 EST
From:     Paul Tanenbaum  &lt;pjt@arl.mil&gt;
To:       moss@arl.mil, karen@arl.mil
cc:       acst@arl.mil
Subject:  New previously existing capability
Message-ID:  &lt;9702071139.aa02573@wolf.arl.mil&gt;

<p>

<p>
Dear MUVES types,
     You may recall that some while ago (probably in the early stages of
AGS) we discussed various ideas about component kill algorithms that
might want to know which face of an object got hit--so one could treat
the front of a radio differently from its bottom, say.  We kicked around
several solutions, including building/converting the component to NMG
so you could have faces as explicitly modeled entities.  We also talked
about MUVES supporting yet another outboard file that would specify
an orientation for each component, so an EM could look at an entry or
exit normal and infer what face was involved.
     Well, in a discussion with Mike yesterday about improvements to our
texture-map shader, I learned that BRL-CAD already makes available pretty
much exactly what you need.  The (struct hit) has a member of type int
called hit_surfno, which encodes the surface of the solid in question.
BTW, for each partition you get a pair of (struct hit)s, one each for
entry and exit.  There is a convention for naming the surfaces of solids
of various types, for instance,

<p>
		ARB8				TGC
	---------------------		---------------------
	Surface #	Face		Surface #	Face
	---------------------		---------------------
	    0           1234
	    1           5678		    1		side
	    2           1485		    2	     top cap
	    3           2376		    3	  bottom cap
	    4           1265		---------------------
	    5           4378
	---------------------

<p>
In the case of the ARB, the modeler even has some control over which face
gets assigned which surface number:  some time ago I implemented a permute
command in MGED that allows one to rearrange the vertex labels of an ARB.
     The bad news is that not all the solid types currently report surface
numbers (e.g. the ARS).  And of course for others, like the SPH or TOR, there
is only one face.  But it shouldn't be too much work for us to police up all
the misbehaving solid types and teach them how to report something sensible.
     So if an EM wanted to be able to treat particular faces of components
differently, one approach would be to support an outboard file mapping lists
of ordered pairs of the form (solid_name, surfno) to component surfaces.
One caution... any such EM would then have an unprecedented sensitivity to
details of the .g file.  For example, if you create one ARB by mirroring
another, they really are mirror images, so their surface numbers will be
mirror image, too.
     To further support this approach, I've enhanced nirt by adding two
output items, surf_num_in and surf_num_out.  This way somebody preparing
target files for MUVES would not have to know the vagaries of the surface
encoding conventions, he can just get in mged, point nirt at the spot he's
interested in, and read off the required surface number(s).
     Paul

<p>
<hr>
<hr>
Received: from localhost by wolf.arl.mil id aa12237; 11 Mar 97 11:36 EST
Date: Tue, 11 Mar 1997 11:36:30 -0500 (EST)
From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" &lt;jra@arl.mil&gt;
To: lynch@whim.arl.mil
cc: ayoung@ww2.arl.mil, scoates@wumpus.arl.mil, ~pjt@wolf.arl.mil,
    ~pjt@worm.arl.mil, mike@wolf.arl.mil, bparker@smokey.arl.mil,
    ~richsand@whale.arl.mil, ~richsand@wharf.arl.mil
Subject: Useful commands in developmental version of MGED
Message-ID: &lt;Pine.SGI.3.95.970311111642.11405A-100000@wolf.arl.mil&gt;
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

<p>

<p>
David,

<p>
	We discussed two useful utilities that I thought might be handy
for your conversions and re-conversions of Pro/E models:

<p>

<p>
	1. Capability to assign idents, air codes, material codes and
	los numbers to BRL-CAD models from a file. The developmental
	version of MGED has an "rcodes" command that will read just
	such a file and assign the codes. The format is nearly the same
	as the output from the "idents" command, but with the first column
	of "region numbers" deleted. (I don't know why the formats are not
	exactly the same). You could do an "idents" command on a model
	already converted from Pro/E (after you have invested the time
	to assign the codes), then edit that file to eliminate the first
	column (see the Unix "cut" command). The result would be useful
	to assign idents to the next version of the Pro/E model that
	comes down the pike. Note that the names of regions would have
	to be the same between the two models.

<p>

<p>
	2. Capability to create a "trail" file that could be fed to MGED
	to re-do all the commands that were performed in an earlier session.
	There is a "journal" command in the developmental version of MGED
	that stores your keyboard commands in an ascii file. This script
	can later be fed to MGED to run the same commands again. Not all
	commands end up in the "journal" file. Solid and object editing
	and mouse/knob/button commands are not included. And I'm  sure
	that commands requiring user interaction (like "edcodes",
	"red", or "ted") will also not be in the "journal" file. However,
	commands, like "r" commands that you would use to correct overlaps,
	would be in the file and could then be run on another file.

<p>

<p>
	These capabilities exist only in the developmental version, but
will be in the next release. I suspect we can arrange something if you
think these capabilities are needed for the Crusader project.

<p>

<p>
		-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058

<p>
AMC says that my views do not represent an official Government position.

<p>
<hr>
<hr>
Received: from localhost by wolf.arl.mil id aa26879; 11 Mar 97 16:56 EST
Date: Tue, 11 Mar 1997 16:56:29 -0500 (EST)
From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" &lt;jra@arl.mil&gt;
To: acst@wolf.arl.mil
Subject: New 'E' command in MGED
Message-ID: &lt;Pine.SGI.3.95.970311164433.26321A-100000@wolf.arl.mil&gt;
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

<p>

<p>
	I have re-written the 'E' command in MGED using the algorithm
I sent out last week. I modified the algorithm slightly in the process.
Originally, I intended to do it all with NMG's, but this was much too
slow. I ended up alowing an option to the 'E' command.

<p>
	With no options, it does it the fastest way, by using the NMG
edges to plot the solids and intersecting the face planes to get the
solid intersection lines, but shooting rays at the original solids. This
is about as fast as the old 'E' command (I believe), but since the NMG
edge/faces don't exactly match the real solid (in curved surfaces),
edges often don't quite match up. In most cases, this is not a problem.

<p>
	When an option is supplied (actually ANY option, but the command
syntax says '-s'), a polysolid version of the solid is used for the
raytracing so that the edges and faces agree exactly with the NMG
version, so edges match. This is still very much faster than than
my original attempt using NMG's all the way, but considerably slower
than with no options.

<p>

<p>
	This nearly completes the conversion of MGED to a database
format independent code.  There are still a few references to db.h
MACROS, and the code to handle the color tables (based on ident numbers)
still uses 'union record'. But that's all, I believe.

<p>
			-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058

<p>
AMC says that my views do not represent an official Government position.

<p>
<hr>
<hr>
Received: from localhost by wolf.arl.mil id aa11926; 15 Apr 97 13:29 EDT
Date: Tue, 15 Apr 1997 13:29:15 -0400 (EDT)
From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" &lt;jra@arl.mil&gt;
To: Bob Strausser &lt;bobs@survice.com&gt;
cc: acst@wolf.arl.mil
Subject: Re: NASTRAN to BRL-CAD
In-Reply-To: &lt;33539F86.C5B@survice.com&gt;
Message-ID: &lt;Pine.SGI.3.95.970415125048.10124A-100000@wolf.arl.mil&gt;
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

<p>
On Tue, 15 Apr 1997, Bob Strausser wrote:

<p>
&gt; Good morning John,
&gt;
&gt; I spoke with Ron Dexter today (apparently my email didn't get to him
&gt; about the PSHELL record).  Based on the "real" -60B NASTRAN file, Ron
&gt; guesses that the PSHELL record could be considered as a plate mode
&gt; indicator.  It only exists (in the -60B) for skin elements and all
&gt; occurrences have a thickness assigned.  Hes not sure that a zero
&gt; thickness would actually be valid in a true NASTRAN file even though
&gt; CATIA outputs a meshed NASTRAN file with a zero thickness entry (the
&gt; sample files).

<p>
	Sounds reasonable to me. Perhaps CATIA is doing just a "surface"
mesh as opposed to a "solid" mesh.

<p>
&gt; He will be sending copies of the latest sample files hes been working
&gt; with and some excerpts from the -60B NASTRAN file.  I'll pass them along
&gt; when they come in.

<p>
	Great, I'll be looking forward to seeing them.

<p>
&gt;                     The CATIA meshed outputs are still CTRIA3 elements
&gt; but I've asked for some other element types from the -60B file.  Based
&gt; on our initial conversion samples, Ron has several questions concerning
&gt; the NASTRAN conversion you're working:
&gt;
&gt; 1.	What is ARL planning / doing concerning the file sizes (NMG and
&gt; polysolid) which are unacceptably large (not practical for working
&gt; with)?  He converted a control rod and had a BRL-CAD file (polysolids)
&gt; that was over 225Kb.  He's noticed that CATIA handles its large file
&gt; sizes fairly well (response times) but BRL-CAD tends to bog down (on the
&gt; same hardware) when its file sizes get to be large (&gt;15 Mb).

<p>
	Both the NMG and the polysolid are very sensitive to tessellation
tolerances. It is very easy to create an outrageously large NMG or
polysolid file from a simple curved surface primitive, just by selecting
a very small tolerance. The polysolid is more compact than the NMG
solid, just a list of polygons. If the files come from CATIA, then CATIA
is creating the polygons.

<p>
	We are investigating the possibility of using some compression
methods which could be applied to these situations, but that will
definitely not be in the next release.

<p>
	My experience has been that MGED will bog down when you try to
display too much geometry, but otherwise runs fairly nicely even with
very large databases.  The two important memory users in MGED are the
display list and the directory of objects. You can have a database
containing only a single object that creates millions of vectors in the
display list when displayed. You may also have a database that contains
millions of objects that create no vectors in the display list when
edited. The large display list can potentially slow down the graphics.
The large number of objects in the database can potentially slow down
everything. When I have seen this behavior it was due to excessive
swapping (not enough memory on the system).  We have been looking at
a new database format for BRL-CAD, perhaps a more compact form for
NMG's and/or polysolids could be considered.

<p>
&gt; 2.	How does ARL plan to handle the non-geometry data in the NASTRAN
&gt; file, given that NASTRAN (as used at Sikorsky) models load paths not
&gt; necessarily physical geometry?  Will the converter be caveated like the
&gt; IGES / AutoCad converters that only XX portions are processed?

<p>
	Currently, the plan is to ignore non-geometry. However, we might
use material ID nunbers from NASTRAN somehow in assigning materials in
BRL-CAD.

<p>
&gt; 3.	Who is ARLs sponsor for the NASTRAN conversion / what are they
&gt; expecting to get out of the NASTRAN file conversion (ties in with the
&gt; non-geometry data aspects)?  Ron is wondering if Sikorsky uses NASTRAN
&gt; differently from other companies - is Sikorsky the only company whose
&gt; NASTRAN files don't "match the physical geometry" of the vehicle (for
&gt; anything but portions of the structure / skin).  If this is an in-house
&gt; effort, Ron may be willing to support with limited file samples.

<p>
	This is an entirely in-house effort. Our FASTGEN competitors
have been touting their capability to convert NASTRAN to FASTGEN as a
reason why they don't want to use BRL-CAD, so we are attempting to quiet
that excuse. I am certainly not a NASTRAN expert, but from what I have
read, it is fairly common for the NASTRAN geometry not to match the
physical geometry. I would appreciate any sample NASTRAN files that
I could get my hands on.

<p>

<p>
			-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058

<p>
AMC says that my views do not represent an official Government position.

<p>
<hr>
<hr>
Received: from localhost by wolf.arl.mil id aa13728; 30 May 97 11:45 EDT
Date: Fri, 30 May 1997 11:45:50 -0400 (EDT)
From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" &lt;jra@arl.mil&gt;
To: Federico Carminati &lt;Federico.Carminati@eet.cern.ch&gt;
cc: acst@wolf.arl.mil
Subject: Re: X-Window interface
In-Reply-To: &lt;n1347110523.8812@EET.CERN.CH&gt;
Message-ID: &lt;Pine.SGI.3.95.970530114401.12696A-100000@wolf.arl.mil&gt;
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

<p>
On 30 May 1997, Federico Carminati wrote:

<p>
&gt;         Reply to:   X-Window interface
&gt;
&gt; Good Morning,
&gt;     one remark on the X-window interface. As you know is very slow, but it can
&gt; be made several times faster changing the line width from 1 to 0. Width 0
&gt; means the hardware default, which is 1 pixel, but much faster (for some
&gt; reason!). All you have to do is to change the third argument of
&gt; XsetLineAttributes in dm-X.c in mged anx xmged. Regards, Carminati
&gt;
&gt;

<p>
	Thanks!!! We tried your suggestion an it does make a significant
improvement. That change will be in the next release.

<p>

<p>
			Thanks again,
			-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058

<p>
AMC says that my views do not represent an official Government position.

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa10390; 30 May 97 10:13 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa25519; 30 May 97 8:45 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa25477; 30 May 97 8:35 EDT
Received: from localhost by wolf.arl.mil id aa06018; 30 May 97 8:32 EDT
Date: Fri, 30 May 1997 08:32:35 -0400 (EDT)
From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" &lt;jra@ARL.MIL&gt;
To: Federico Carminati &lt;Federico.Carminati@eet.cern.ch&gt;
cc: ged@walrus.arl.mil
Subject: Re: BUG in BRL?
In-Reply-To: &lt;n1347290506.81631@EET.CERN.CH&gt;
Message-ID: &lt;Pine.SGI.3.95.970530081504.5189B-100000@wolf.arl.mil&gt;
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

<p>
On 28 May 1997, Federico Carminati wrote:

<p>
&gt;         Reply to:   RE&gt;&gt;BUG in BRL?
&gt;
&gt; Good morning,
&gt;    thank you for your quick answer. In fact I was not sure, so I continued
&gt; investigating in the problem. Now I do have the right answers, but I still do
&gt; not understand why. I have a box with a hole, and in the hole a cylinder which
&gt; fills it completely. I have constructed it with the following input:
&gt;
&gt; killall *
&gt; press reset
&gt; title TARC Lead Block
&gt; units m
&gt; in block.s box -0.075 -0.075 -0.075 0.15 0 0 0 0.15 0 0 0 0.15
&gt; in hollow.s rcc 0 0 -0.080 0 0 0.160 0.032
&gt; in hole.s rcc 0 0 -0.075 0 0 0.150 0.032
&gt; regdef 1
&gt; r block.r + block.s - hollow.s
&gt; r hole.r + hole.s
&gt; g block.g block.r hole.r
&gt; size 0.5
&gt; B block.g
&gt;
&gt; Then I wrote a very simple application which, given a ray (inside the model!)
&gt; returns the distance to the first (i.e. closest) hit. And I set onehit=1. What
&gt; happens then is that all rays starting in the quadrant x&gt;-0.032 y&gt;-0.032
&gt; intersect the cylinder correctly, while all the other do not see it and go
&gt; directly to the border of the box.
&gt; If I set onehit=2, I still have one only hit in the hit routine, and I can
&gt; tell because p-&gt;part_forw-&gt;part_forw == p, but this time it is the right one!
&gt; The fact is that I want only the first hit, so I thought that onehit should be
&gt; one. So now it works but I do not see why. Regards and thank you again for
&gt; your help. Carminati

<p>

<p>
	It looks like you are confusing ``partitions'' withs ``hits''.
Each ``partition'' structure has pointers to two ``hits''. A ``hit''
is an intersection between the ray and an object surface. A
``partition'' is a length of the ray that is entirely within an object.
The ``partition'' extends from an entrance ``hit'' (pt_inhit) to an exit
``hit'' (pt_outhit).

<p>
	The ``onehit'' flag sets the desired number of ``hits''.  If
``onehit'' is set to one, then only the first ``pt_inhit'' is valid.

<p>
	Another consideration is that if you fire a ray from within a
solid object, then the ray will also be traced backward to find the
``pt_inhit'' point, as well as forward to find the ``pt_outhit''. Note
that, in this case, the ``hit_dist'' for the ``pt_inhit'' will be less
than zero. However, if ``onehit'' is one, only the ``pt_inhit'' will be
valid.

<p>
	If you set ``onehit'' to two, you should only get one
``partition'' (which is two hits), and both hits will be valid.

<p>

<p>

<p>
			Hope this helps,
			-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058

<p>
AMC says that my views do not represent an official Government position.

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa05898; 13 Jun 97 17:15 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa00891; 13 Jun 97 16:06 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa00857; 13 Jun 97 15:57 EDT
Received: from localhost by wolf.arl.mil id aa02539; 13 Jun 97 15:54 EDT
Date: Fri, 13 Jun 1997 15:54:04 -0400 (EDT)
From: "Lee A. Butler" &lt;butler@ARL.MIL&gt;
To: gdpayne@dra.hmg.gb
cc: cad@ARL.MIL
Subject: Re: BRLCAD r5
In-Reply-To: &lt;9706130855.aa13035@wharf.arl.mil&gt;
Message-ID: &lt;Pine.SGI.3.95.970613154638.2138A-100000@wolf.arl.mil&gt;
X-URL: http://ftp.arl.mil/~butler/
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

<p>
On Fri, 13 Jun 1997 gdpayne@dra.hmg.gb wrote:

<p>
&gt; Now that it looks like BRLCAD release 5 is coming over the horizon,
&gt; is it possible to get a copy of the expected feature list for the new
&gt; version ?

<p>
The most significant changes that you will notice are:

	completeley new mged (better than xmged) based upon Tcl/Tk
	no xmged
	OpenGL support for both framebuffer and mged.
	greatly improved booleans of NMG's
	new converters
		VRML - can convert from BRL-CAD to VRML only
			This conforms to VRML 1.0.

<p>
		ACAD - can convert from BRL-CAD to ACAD only
			The ACAD format used is entirely triangular
			facets.

<p>
		Laser scan - can convert from laser scan data to BRL-CAD only
			This code is currently limited to Cyberware Digitizer
			Data in cylindrical scan format and is limited to
			simple shapes only.

<p>
		Wavefront - can export polygons in Wavfront .obj format

<p>
	new shaders
		camo	cammoflage
		air/fog (homogenous mist)
		noise	(fBm/turbulence effects on color/surface_normal)
		cloud	Noise-based "solid cloud" shader
		fire	reminicient of brush-fire type flames

<p>
	librt extensively reorganized
	new utility and numerical handling libraries (broken out from librt)

<p>
&gt; We are particularly interested in the BRLCAD to polygon convertor
&gt; which was expected to form part of the new release. How well does
&gt; this work ?

<p>
It's still not foolproof.  But it does a better job now.

<p>
&gt; Are we likely to see online / downloadable manuals for the new
&gt; version? Online manuals for the old version seemed to wither away
&gt; after the first few elements were completed.

<p>
There is a fair bit of documentation that has been written for the new
release.  Especially on the new mged.  We are doing what we can to extend
and improve the documentation.  It will be available online, and as a part of
the distribution.  Summary:  The documentation will be better, but it still
won't be ... what I wish it was.

<p>
Lee A. Butler					Internet: butler@arl.mil
Attn: AMSRL-SL-BV				Phone: (410) 278-9200
U.S. Army Research Laboratory			DSN:	     298-9200
Aberdeen Proving Ground, MD  21005-5068		FAX:   (410) 278-5058

<p>
As nightfall does not come at once, neither does oppression.  In both
instances, there is a twilight when everything remains seemingly unchanged.
And it is in such twilight that we all must be most aware of change in the
air--however slight--lest we become unwitting victims of the darkness.
--- Justice William O. Douglas

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa21381; 23 Jun 97 21:31 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa15194; 23 Jun 97 20:54 EDT
Received: from wharf.arl.mil by WALRUS.ARL.MIL id aa15169; 23 Jun 97 20:49 EDT
Received: from trantor.dso.org.sg by wharf.arl.mil id aa12887;
          23 Jun 97 20:49 EDT
Received: from demerzel.dso.org.sg (demerzel.dso.org.sg [192.190.204.8])
	by trantor.dso.org.sg (8.8.5/8.8.5) with ESMTP id IAA20207
	for &lt;cad@arl.mil&gt;; Tue, 24 Jun 1997 08:57:09 +0800 (SST)
Received: (from cmeiteng@localhost)
	by demerzel.dso.org.sg (8.8.5/8.8.5) id IAA21160
	for cad@arl.mil; Tue, 24 Jun 1997 08:49:22 +0800 (SGT)
From: Cheong Mei Teng &lt;cmeiteng@dso.org.sg&gt;
Message-Id: &lt;199706240049.IAA21160@demerzel.dso.org.sg&gt;
Subject: BRL-CAD questions
To: cad@ARL.MIL
Date: Tue, 24 Jun 1997 08:49:22 +0800 (SGT)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

<p>
 I am currently using BRL-CAD Ver 4.0 and AutoCad Release 12.
 My intention is to use AutoCad to generate either an IGES-file or DXF-file,
 and ask BRL-CAD to read it as a G-file. I have problems in both cases.

 1. I exported a 3-D drawing into an IGES-file from AutoCad 12.The drawing
 does not contain any solids, everything is in terms of lines and mesh. Then
 i used
         iges-g -o file.g file.igs
 the program ran, but it gave me a flattened 2-D drawing in mged. it appears
 that the 3rd dimension is not being taken care of. i tried it with other
 flags, but to no avail. the help file for iges-g indicates that the program
 recognises only the IGES 5.1. i think AutoCad 12's IGES is not 5.1.
 what do you think is the problem here? is it the IGES version which is the
 culprit? do you know of any CAD drawers whose IGES is compatible with BRL-CAD?

 2. I repeated the same procedure with a DXF-file from AutoCad 12. the help
 did indicate that the dxf-g works for Autodesk greater than 10 (i think). i
 tried
         dxf-g -i file.dxf -o file.g
 and an error indicates that an unexpected EOF is detected in input file. i
 removed the EOF line in the input file, still the same error. i tried
         dxf-g &lt;file.dxf&gt; file.g
 the program ran, but an empty G-file was created, in a sense, no drawing was
 shown in mged.
 what do you think is the problem here? is it a version thing again? if it
 is, do you know of any CAD drawers which will work with their dxf files?

<p>
Thank You !
&gt;

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa15802; 24 Jun 97 8:26 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa19600; 24 Jun 97 8:25 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa19477; 24 Jun 97 8:14 EDT
Received: from localhost by wolf.arl.mil id aa15058; 24 Jun 97 8:09 EDT
Date: Tue, 24 Jun 1997 08:09:15 -0400 (EDT)
From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" &lt;jra@ARL.MIL&gt;
To: Cheong Mei Teng &lt;cmeiteng@dso.org.sg&gt;
cc: cad@ARL.MIL
Subject: Re: BRL-CAD questions
In-Reply-To: &lt;199706240049.IAA21160@demerzel.dso.org.sg&gt;
Message-ID: &lt;Pine.SGI.3.95.970624080201.14561A-100000@wolf.arl.mil&gt;
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

<p>
On Tue, 24 Jun 1997, Cheong Mei Teng wrote:

<p>
&gt;  I am currently using BRL-CAD Ver 4.0 and AutoCad Release 12.
&gt;  My intention is to use AutoCad to generate either an IGES-file or DXF-file,
&gt;  and ask BRL-CAD to read it as a G-file. I have problems in both cases.
&gt;
&gt;  1. I exported a 3-D drawing into an IGES-file from AutoCad 12.The drawing
&gt;  does not contain any solids, everything is in terms of lines and mesh. Then
&gt;  i used
&gt;          iges-g -o file.g file.igs
&gt;  the program ran, but it gave me a flattened 2-D drawing in mged. it appears
&gt;  that the 3rd dimension is not being taken care of. i tried it with other
&gt;  flags, but to no avail. the help file for iges-g indicates that the program
&gt;  recognises only the IGES 5.1. i think AutoCad 12's IGES is not 5.1.
&gt;  what do you think is the problem here? is it the IGES version which is the
&gt;  culprit? do you know of any CAD drawers whose IGES is compatible with BRL-CAD?

<p>
	This is the correct result. When AutoCad exports a drawing to IGES, it
flattens it.

<p>
&gt;  2. I repeated the same procedure with a DXF-file from AutoCad 12. the help
&gt;  did indicate that the dxf-g works for Autodesk greater than 10 (i think). i
&gt;  tried
&gt;          dxf-g -i file.dxf -o file.g
&gt;  and an error indicates that an unexpected EOF is detected in input file. i
&gt;  removed the EOF line in the input file, still the same error. i tried
&gt;          dxf-g &lt;file.dxf&gt; file.g
&gt;  the program ran, but an empty G-file was created, in a sense, no drawing was
&gt;  shown in mged.
&gt;  what do you think is the problem here? is it a version thing again? if it
&gt;  is, do you know of any CAD drawers which will work with their dxf files?

<p>
	Our DXF to BRL-CAD converter only considers 3DFACES and 3DMESH objects
in the DXF file. A drawing (2D or 3D) will not have either of these.

<p>
	BRL-CAD is solid modeling system with very little support for
"drawings". Generally, all objects in a BRL-CAD model are solids. You
might try creating a solid model in AutoCad and converting that to
BRL-CAD via either DXF or IGES.

<p>

<p>

<p>
			-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058

<p>
AMC says that my views do not represent an official Government position.

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa14639; 23 Jul 97 10:27 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa01613; 23 Jul 97 9:44 EDT
Received: from admii.arl.mil by WALRUS.ARL.MIL id aa01555; 23 Jul 97 9:37 EDT
Received: from survice.com by ADMII.ARL.MIL id aa12363; 23 Jul 97 9:11 EDT
Received: from 206.181.114.201 by server.survice.com via SMTP (940816.SGI.8.6.9/940406.SGI)
	 id JAA09027; Wed, 23 Jul 1997 09:14:57 -0400
Message-ID: &lt;33D6037C.5A59@survice.com&gt;
Date: Wed, 23 Jul 1997 09:13:44 -0400
From: Bob Strausser &lt;bobs@survice.com&gt;
Organization: The SURVICE Engineering Co. / SURVIAC ASO
X-Mailer: Mozilla 3.01 (Macintosh; I; PPC)
MIME-Version: 1.0
To: frost &lt;jlseagul@world-net.net&gt;
CC: cad@ARL.MIL
Subject: Re: brlcad-startup/display
References: &lt;199707230211.VAA22387@ns1.world-net.net&gt;
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

<p>
on 22 Jul 1997, frost wrote:
&gt; When I startup brlcad's mged I use for an example:

<p>
&gt; cd /usr/brlcad/db    # this puts me in the sample dir.
&gt; mged cube.g          # to start the editor using cube.g
&gt; attach (nu|tek|tek4109|ps|plot|X|)[nu]       # what it asks me
&gt; X                    # my answer (I think this uses the "X" display)
&gt; Xdisplay [:0.0]?     # what it asks me
&gt; "enter"              # I hit enter in responce

<p>
&gt; At this point the editor pulls up, but all that can be seen is a dot &gt; in the center of the screen.  I've tried zooming in using the slide &gt; bar, but this seems to do nothing.  Is this normal, is there
&gt; something I not doing, Is there something I need to check.

<p>
Yes that is normal behavior.

<p>
What you have accomplished at this point is opening a geometry database
and attaching a graphic display window.

<p>
The program is now waiting for you to tell it what to do.  You have a
text window to type commands into and a graphic window for wireframe
displays and mouse commands.  The white dot (in the graphic display) is
the location of the 'center' of the 'camera - eyepoint' focus.  Its
X/Y/Z coordinate value in three dimensional space should be listed in
the lower left corner of the graphical display.

<p>
You can list the commands by typing "?" (no quote symbols) and pressing
return.  Typing "help" and pressing return includes the usage syntax for
the commands (scrolling your window).  Typing "help command" (replace
command with one of the commands from the list) will echo to the text
window the usage syntax for just that command.

<p>
Since you opened an existing geometry database, you should type "tops"
and press return.  This will list all of the database objects which are
on the top level (not members in a group or region).  For the cube.g
file the top level objects are:

<p>
all.g/              cloud.r.bak/R       light.r/R

<p>
where all.g is a group of regions and groups, cloud.r.bak is a region
containing solids, and light.r is a region (with a single solid) which
has been defined as a light source (internal to the geometry as opposed
to the default 'camera - eyepoint' light sources).

<p>
Typing "e all.g"&lt;return&gt; will display the object all.g on the graphic
display window as a wireframe representation of all the solids at the
root of the all.g heirarchical tree.  This is identified as 'viewing'
mode.  You can use the mouse in the graphic window or commands typed in
the text window to change the viewing angle, size, and location.

<p>
Solid edit mode will permit you to change the individual coordinate
parameters which define a solid object - its individual length, width,
height, radius, location in space, and orientation.

<p>
Object edit mode will permit you to change a collection of region and
group objects with regard to their location, orientation, and overall
size in space.  The solids which are the defining root of the regions
and groups still retain the same (original) coordinate data defined in
their respective individual solid edit mode sessions.  Object edit
changes may be pushed to the root solids (changing the solids'
coordinate data) if there are no conflicts.  A conflict occurs when a
solid is used in multiple regions and the regions (or groups containing
those regions) have been object edited to different
locations/orientations/scales.

<p>
Bob Strausser
SURVIAC Aberdeen Satellite Office
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa29474; 23 Jul 97 16:19 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa06125; 23 Jul 97 15:26 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa06091; 23 Jul 97 15:16 EDT
Received: from wolf.arl.mil by wolf.arl.mil id aa26653; 23 Jul 97 15:12 EDT
Date: Wed, 23 Jul 1997 15:12:02 -0400 (EDT)
From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" &lt;jra@ARL.MIL&gt;
To: RDexter@zoomit.sikorsky.com
cc: cad@ARL.MIL
Subject: Re: How to quickly remove edcodes assigned data
In-Reply-To: &lt;0000bdbxfhjf.0000amyywkio@zoomit.sikorsky.com&gt;
Message-ID: &lt;Pine.SGI.3.95.970723150808.26169A-100000@wolf.arl.mil&gt;
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

<p>
On 23 Jul 1997 RDexter@zoomit.sikorsky.com wrote:

<p>
&gt; Is there a quick way to remove all of the edcode assigned
&gt; colors, materials, etc. from within a model database to
&gt; "clean-up" a description?
&gt;
&gt; Thanks in advance.
&gt;
&gt; &gt;&gt;  Ron Dexter
&gt;       Survivability & Low Observables
&gt;       Sikorsky Aircraft Corporation
&gt;       PH:  (203) 386-7922     FX:  (203) 386-5925
&gt;       EM:  rdexter@sikorsky.com
&gt;
&gt;
&gt;

<p>
Ron,

<p>
	The easiest way I know of (using the distributed MGED) is to use
the "idents" command to get the current data in a file, then edit that
file into a list of "edcomb" commands to accomplish whatever you want
with the edcodes info. Then use execute MGED using that file for
redirected input.

<p>
	By the way, "edcodes" does not set the color, just ident, air
code, GIFT material code, and LOS.

<p>

<p>
		-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058

<p>
AMC says that my views do not represent an official Government position.

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa11052; 12 Sep 97 9:55 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa03997; 12 Sep 97 8:45 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa03941; 12 Sep 97 8:36 EDT
Received: from wolf.arl.mil by wolf.arl.mil id aa07320; 12 Sep 97 8:24 EDT
Date: Fri, 12 Sep 1997 08:24:03 -0400 (EDT)
From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" &lt;jra@ARL.MIL&gt;
To: Tom Browder &lt;tbrowde@asi-fwb.com&gt;
cc: cad@ARL.MIL
Subject: Re: Cake and gen.sh
In-Reply-To: &lt;Pine.LNX.3.95.970911141746.4580A-100000@tomtom.asi-fwb.com&gt;
Message-ID: &lt;Pine.SGI.3.95.970912081956.6540B-100000@wolf.arl.mil&gt;
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

<p>
On Thu, 11 Sep 1997, Tom Browder wrote:

<p>
&gt; Is there any easy way to get the BIG
&gt; compilation process to HALT at the first
&gt; compile error?
&gt;
&gt; Thanks.
&gt;
&gt; Tom Browder
&gt;
&gt;
&gt;
&gt;

<p>
	In the file "gen.sh" at about line #297, you will find the
section of the script which drives the "BIG" compilation ("cake all").
You might try changing "cake -k" to "cake -a". The "-k" option says
"don't abort" while the "-a" option says "abort the whole run if cake
sees an action return with a nonzero status".

<p>

<p>
			-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058

<p>
AMC says that my views do not represent an official Government position.

<p>
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa25548; 2 Oct 97 18:59 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa18244; 2 Oct 97 17:34 EDT
Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa18206; 2 Oct 97 17:24 EDT
Received: from wolf.arl.mil by wolf.arl.mil id aa21639; 2 Oct 97 17:22 EDT
Date: Thu, 2 Oct 1997 17:22:11 -0400 (EDT)
From: "Lee A. Butler" &lt;butler@ARL.MIL&gt;
To: Tom Browder &lt;tbrowde@asi-fwb.com&gt;
cc: cad@ARL.MIL
Subject: Re: mged and inmem data base
In-Reply-To: &lt;Pine.LNX.3.95.970930132822.5103A-100000@tomtom.asi-fwb.com&gt;
Message-ID: &lt;Pine.SGI.3.95.971002161003.18673A-100000@wolf.arl.mil&gt;
X-URL: http://ftp.arl.mil/~butler/
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

<p>
On Tue, 30 Sep 1997, Tom Browder wrote:
&gt; We are working on larger and larger models, and
&gt; see slower and slower results during typical
&gt; mged operations such as 'tops', 'e', etc.
&gt; We are using PC Linux and SGI IRIX hosts and the
&gt; behavior is seen on both.
&gt; It sounds as if mged goes to the disk for
&gt; each mged data base command, even if nothing
&gt; is changed. The question is, is this behavior
&gt; correct?

<p>
This is correct.  The original design goals for MGED included that the
database file should always be in a stable state.  All actions on the database
are as atomic as we could make them.  Thus if the machine went down in the
middle of an edit, you would loose very little.

<p>
Modern practice for editors (text and otherwise) tends to emphasize speed
at the cost of reliability.  As a result the tendecy is to read the whole file
into memory, operate on it, and only write to disk under direct user
guidance.  This has limitations in terms of the size and complexity of the
database to be edited.

<p>
Both approaches have drawbacks.

<p>
Realize that the "tops" command has to process each item in the database.
Ergo, the larger the database, the longer tops will take.  As for "e", that
should only slow down when the number of objects you are displaying goes
up.  If you "e" up 1000 solids, it's going to take longer than if you "e"
up 10.

<p>
Lee A. Butler					Internet: butler@arl.mil
Attn: AMSRL-SL-BV				Phone: (410) 278-9200
U.S. Army Research Laboratory			DSN:	     298-9200
Aberdeen Proving Ground, MD  21005-5068		FAX:   (410) 278-5058

<p>
As nightfall does not come at once, neither does oppression.  In both
instances, there is a twilight when everything remains seemingly unchanged.
And it is in such twilight that we all must be most aware of change in the
air--however slight--lest we become unwitting victims of the darkness.
--- Justice William O. Douglas

<p>
<hr>
<hr>
Date:     Tue, 23 Dec 97 4:05:01 EST
From:     Mike Muuss  &lt;mike@arl.mil&gt;
To:       ACST@arl.mil
cc:       CJohnson@netgsi.com
Subject:  bn_mat_ck()
Message-ID:  &lt;9712230405.aa04509@vm.arl.mil&gt;

<p>

<p>
There is a new LIBBN routine called bn_mat_ck() which can be used to
ensure that a rotation matrix preserves axis perpendicularity and
doesn't have a scale factor of zero.  Handy when your matricies are
getting corrupted and you aren't sure where it's happening.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from vapor.arl.mil by wolf.arl.mil id aa13640; 23 Dec 97 5:12 EST
Date:     Tue, 23 Dec 97 5:05:42 EST
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       ACST@ARL.MIL
cc:       lorenzo@nvl.army.mil, russ@nvl.army.mil, mbaldwin@nvl.army.mil,
          dflorek@nvl.army.mil, dtidrow@nvl.army.mil, CJohnson@netgsi.com
Subject:  mged displaylist updating
Message-ID:  &lt;9712230505.aa15453@VJ.ARL.MIL&gt;

<p>

<p>
This evening, after a tremendous amount of infrastructure work in
librt/db_tree.c, I've finally been able to fix on the bug in MGED,
whereby adjusting the color of a region and giving the "redraw_vlist"
command gets the color updated on the screen.

<p>
Also, if I "B" or "e" the object after changing it, the screen shows the
new color.

<p>
Here is an example of how to reproduce it:

<p>
19 vj&gt; ./mged -n ../.db.6d/moss.g
BRL-CAD Release 4.5   Graphics Editor (MGED)
    Tue Dec 23 04:40:51 EST 1997, Compilation 6633
    mike@vapor.arl.mil:/m/cad/.mged.6d

<p>
Gary Moss's "World on a Platter" (units=mm)
attach (nu|X|ogl|glx)[nu]? glx
mged&gt; e light.r
51 vectors in 0.001403 sec
mged&gt; .inmem adjust light.r rgb {0 255 0}
mged&gt; redraw_vlist light.r
light.r/LIGHT

<p>
The light sphere turns green.  Yay!

<p>
This also means that the "sun" turns yellow in the MGED window in
"dynamic geometry" demo, just like it does in the ray-traced view.
A very important bit of progress, as much will be built on this.

<p>
	Best,
	 -Mike

<p>
<hr>
<hr>
Received: from vapor.arl.mil by wolf.arl.mil id aa06743; 6 Jan 98 23:28 EST
Date:     Tue, 6 Jan 98 23:18:48 EST
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       ACST@ARL.MIL
Subject:  mged "shader" cmd changed
Message-ID:  &lt;9801062318.aa11605@VJ.ARL.MIL&gt;

<p>

<p>
&gt;&gt; Modified "shader" command so that it returns current shader if
&gt;&gt; a new material string isn't given.
&gt;&gt; Even on a read-only database.

<p>
Probably a number of other commands ought to work like that too, to
make them more useful in building Tcl scripts.

<p>
	Best,
	-Mike
<hr>
<hr>
Received: from wolf.arl.mil by wolf.arl.mil id aa28831; 16 Jan 98 15:49 EST
Date: Fri, 16 Jan 1998 15:49:42 -0500 (EST)
From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" &lt;jra@arl.mil&gt;
To: ~jill@slad.arl.mil, ~jill@wharf.arl.mil, Jill_Smith@mail.arl.mil
cc: acst@wolf.arl.mil
Subject: Slow BRL-CAD Raytracing
Message-ID: &lt;Pine.SGI.3.95.980116152819.27969B-100000@wolf.arl.mil&gt;
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

<p>
Jill,

<p>
	Mark Burdeshaw (now of ARA) asked me to stop by to discuss the
problem that some SURVICE people were having with BRL-CAD raytracing
(someone claimed BRL-CAD was ~400 times slower than FASTGEN, I believe).

<p>
	SURVICE is developing a sort of "seeker" model for AJEM (funded
by JTCG). They are using a FASTGEN model (converted to BRL-CAD) as the
target being seeked. The seeker model uses librt raytracing to simulate
whatever the real seeking technique is, so many rays are fired in the
direction of the target. It turns out that when the target was converted
from FASTGEN (using patch-g), it was converted into NMG solids. Remember
that we are talking release 4.4 here, NMG raytracing was still
experimental and extremely slow. It was easy to spot this problem (their
profile listing showed "rt_isect_faceuse" as a big time consumer). I
suggested that they re-convert the FASTGEN model using the "-p" option
to patch-g (this creates polysolids rather than NMG solids). Just using
polysolids instead of NMG solids should improve their raytracing
performance immensely.

<p>
	I should point out that the documentation for patch-g does not
mention the "-p" option (an oversight on my part). In the next
release(?), patch-g will produce polysolids by default, and the user
will be required to provide an option to get NMG solids.

<p>

<p>
			-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058

<p>
AMC says that my views do not represent an official Government position.

<p>
<hr>
<hr>
Received: from vapor.arl.mil by wolf.arl.mil id aa11775; 22 Jan 98 21:12 EST
Date:     Thu, 22 Jan 98 21:11:20 EST
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       ACST@ARL.MIL
Subject:  rt -j flag
Message-ID:  &lt;9801222111.aa01537@VJ.ARL.MIL&gt;

<p>

<p>
This afternoon John and I implemented the -j flag to RT, allowing the
specification of a sub-rectangle within screen space to be specified.
Ray-tracing is limited to those pixels within the sub-rectangle.

<p>
This support was needed so that Bob could implement the
"sweep out a rectangle for ray-tracing" capability in MGED.

<p>
Dynamic scanline buffering and full load-balanced parallel support
are working.  Incremental mode (-i) isn't working yet.

<p>
Man page has been updated.

<p>
	Best,
	 -Mike
<hr>
<hr>
Date:     Tue, 27 Jan 98 22:15:31 EST
From:     Mike Muuss  &lt;mike@arl.mil&gt;
To:       John R. Anderson &lt;jra@arl.mil&gt;
cc:       Mark Becker &lt;mbecker@sunmil1.uml.edu&gt;, pjt@arl.mil, mike@arl.mil
Subject:  Re: mged.ps in reverse order?
Message-ID:  &lt;9801272215.aa21481@wolf.arl.mil&gt;

<p>

<p>
Mark wrote -

<p>
&gt; Umm... mged.ps was generated with some kind of reverse-page option
&gt; such the first printed page is the last page of the document.

<p>
Yes, it was intended to be that way.  Something to do with the way
that Bill's Apple LaserWriter handled the paper.

<p>
On some printers, you can flip down a door to have the pages stacked in
the other order.

<p>
&gt; Do you have the TeX (or LaTeX) source for mged.ps available on-line?
&gt; I'd like to generate the .ps file for double-sided printing and
&gt; correct ordering.

<p>
Sure, the TeX version is a standard part of the distribution, as a SHAR
archive in doc/mged.tr, feel free to print from that instead.

<p>
The whole reason I provided the .ps file was because some folks were
having difficulty printing the TeX files on a modern version of TeX.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.arl.mil by wolf.arl.mil id aa24950; 17 Mar 98 8:30 EST
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa26800; 17 Mar 98 8:19 EST
Received: from worm.arl.mil by WALRUS.ARL.MIL id aa26771; 17 Mar 98 8:16 EST
Received: from worm.arl.mil by WORM.ARL.MIL id aa04745; 17 Mar 98 8:14 EST
Date: Tue, 17 Mar 1998 08:14:22 -0500 (EST)
From: "Gary S. Moss (BVLD/VMB) &lt;moss&gt;" &lt;moss@ARL.MIL&gt;
To: cad@ARL.MIL
Subject: Re: lgt and pixfile size
In-Reply-To: &lt;9803061452.aa14708@WUMPUS.ARL.MIL&gt;
Message-ID: &lt;Pine.SGI.3.95.980317080341.4558A-100000@worm.arl.mil&gt;
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

<p>
Carl,

<p>
	Sorry to take so long to respond, but as you surmise, LGT assumes
a square frame buffer.  This is a throwback from it's origin using square
standalone frame buffers rather than workstations with built-in graphics.
Except for very minor porting to new OS releases, LGT has undergone
virtually no change in 10 years or more and it shows.

<p>
-Gary

<p>
On Fri, 6 Mar 1998, Carl Moore wrote:

<p>
&gt; I used a script which ran lgt and made an outline drawing in black which
&gt; was put onto a white background in a .pix file.  There is a slight incon-
&gt; venience, since I usually work with full-screen .pix files: the .pix file
&gt; from said lgt run was 1024 x 1024.  The workaround to get it into a full-
&gt; screen (1280 x 1024) size file is to bring the 1024 x 1024 .pix file into
&gt; my frame buffer, then run fb-pix with the 1280 x 1024 size selected in its
&gt; parameters.
&gt;
&gt; Did I miss something or did I see that lgt could only create square (i.e.
&gt; same number of pixels horizontal & vertical) .pix files?
&gt;

<p>

<p>
   _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
  _/       Gary S. Moss         email:  moss@arl.mil              _/
 _/  Computer Scientist         WWW:    http://web.arl.mil/~moss _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

<p>

<p>
<hr>
<hr>
Received: from vapor.arl.mil by wolf.arl.mil id aa28682; 26 Mar 98 23:15 EST
Date:     Thu, 26 Mar 98 23:07:44 EST
From:     Mike Muuss &lt;mike@ARL.MIL&gt;
To:       acst@ARL.MIL
cc:       Kermit@ARL.MIL, Keith@ARL.MIL, Phil@ARL.MIL
Subject:  rfbd dropped, guts moved to LIBFB
Message-ID:  &lt;9803262307.aa16316@VJ.ARL.MIL&gt;

<p>

<p>
This evening I decided to eliminate the RFBD program; nobody uses it any
more, it's been replaced by FBSERV.

<p>
I've also moved the guts (event handlers) of FBSERV to libfb/server.c.
I was going to try and get MGED to use the LIBFB routines, but
couldn't because of the way Bob had to #define the fbp variable
to make it part of the current dm context.  Oh well, was worth a try.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from wolf.arl.mil by CAD.ARL.MIL id aa08874; 15 Apr 98 1:28 EDT
Received: from vapor.arl.mil by wolf.arl.mil id aa22823; 15 Apr 98 1:20 EDT
Date:     Wed, 15 Apr 98 1:18:55 EDT
From:     Mike Muuss &lt;mike@arl.mil&gt;
To:       Lamas@arl.mil
Subject:  bu_parallel() got extra arg
Message-ID:  &lt;9804150118.aa04962@VJ.ARL.MIL&gt;

<p>

<p>
This evening I modified the calling sequence to libbu/bu_parallel()
so that threads are started with one additional parameter, a
caller-supplied void *, which can be used to pass in a private
state structure.

<p>
This allowed me to eliminate some ugly use of global state variables
in db_tree.c and cut.c, and allowed me to make db_walk_tree() fully
recursive even in parallel mode, which is something that Lee and I
have been wanting for a long time, and I need to have now to hit one
of my TAPES bullets. :-)

<p>
If you encounter something I didn't convert, the extra arg may safely
be provided as NULL.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from walrus.arl.mil by CAD.ARL.MIL id aa06460; 21 May 98 15:53 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id ab01990; 21 May 98 15:45 EDT
Received: from admii.arl.mil by WALRUS.ARL.MIL id aa01935; 21 May 98 15:42 EDT
Received: from sunmil2.uml.edu by ADMII.ARL.MIL id aa19766; 21 May 98 15:29 EDT
Received: (from mbecker@localhost)
	by sunmil2.uml.edu (8.8.8/8.8.8) id PAA13296;
	Thu, 21 May 1998 15:29:58 -0400 (EDT)
Date: Thu, 21 May 1998 15:29:58 -0400 (EDT)
Message-Id: &lt;199805211929.PAA13296@sunmil2.uml.edu&gt;
From: Mark Becker &lt;mbecker@sunmil2.uml.edu&gt;
To: CAD@ARL.MIL
Subject: AutoCAD and BRL-CAD
Reply-to: mbecker@sunmil2.uml.edu

<p>
Hello * -

<p>
For the past couple of weeks I've been trying to find a combination of
AutoCAD and BRL-CAD tools to permit the exchange of images between the
two systems.

<p>
My test drawing (in the AutoCAD world) is of a cube with a small
rectangular cavity in one side.  My most recent success has been in
setting AutoCAD to output the drawing in "B-REP solid with analytical
surfaces" and using iges-g to translate to BRL-CAD g-format.

<p>
This works.. partway.  In an attempt to raytrace the object, 'rt' runs
for a while, emits a message "This better be a 2-manifold surface" and
dumps core (Platform: UltraSparc 2 with Solaris 2.5.1, running BRLCAD
4.5).

<p>
The same behaviour occurs when dealing with a "B-REP solid with NURB
surfaces."

<p>
Another curiousity is that modelling the cube-with-cavity in BRLCAD
shows the cavity with dotted-lines (indicating a subtraction?) but
modelling the AutoCAD-modelled cube-with-cavity has solid cavity
lines.

<p>

<p>
Suggestions?

<p>
Your time is appreciated.

<p>
Regards,

<p>
Mark
<hr>
<hr>
Received: from walrus.arl.mil by CAD.ARL.MIL id aa04004; 2 Jun 98 18:59 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa23132; 2 Jun 98 18:04 EDT
Received: from cad.arl.mil by WALRUS.ARL.MIL id aa23079; 2 Jun 98 17:54 EDT
Received: from cad.arl.mil by CAD.ARL.MIL id aa25168; 2 Jun 98 17:17 EDT
Date: Tue, 2 Jun 1998 17:17:29 -0400 (EDT)
From: "Lee A. Butler" &lt;butler@ARL.MIL&gt;
To: Mark Becker &lt;mbecker@sunmil2.uml.edu&gt;
cc: CAD@ARL.MIL
Subject: Re: AutoCAD and BRL-CAD
In-Reply-To: &lt;199805211929.PAA13296@sunmil2.uml.edu&gt;
Message-ID: &lt;Pine.SGI.3.95.980602164732.19570C-100000@cad.arl.mil&gt;
X-URL: http://ftp.arl.mil/~butler/
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

<p>
On Thu, 21 May 1998, Mark Becker wrote:
&gt; For the past couple of weeks I've been trying to find a combination of
&gt; AutoCAD and BRL-CAD tools to permit the exchange of images between the
&gt; two systems.
&gt;
&gt; My test drawing (in the AutoCAD world) is of a cube with a small
&gt; rectangular cavity in one side.  My most recent success has been in
&gt; setting AutoCAD to output the drawing in "B-REP solid with analytical
&gt; surfaces" and using iges-g to translate to BRL-CAD g-format.
&gt;
&gt; This works.. partway.  In an attempt to raytrace the object, 'rt' runs
&gt; for a while, emits a message "This better be a 2-manifold surface" and
&gt; dumps core (Platform: UltraSparc 2 with Solaris 2.5.1, running BRLCAD
&gt; 4.5).

<p>
This implies that you are creating a B-REP NMG solid in BRL-CAD for your
object.  The NMG code in release 4.x is what I would call "experimental"
in quality.  However, for some database formats, it is the only way to
achieve a conversion.

<p>
In your case, it seems that you are not creating a closed solid, but rather
a collection of planar surfaces which touch but are not topologically
connected.  You may wish to investigate the "asc-nmg" program.

<p>
In some cases, there are large performance improvements which can be achieved
by re-modeling the object (or parts of it) in BRL-CAD.  For example,
ray-tracing a BRL-CAD object consisting of an arb8 with a subtracted arb8 will
be much faster than ray-tracing the equivalent NMG planar suface
representation.

<p>
For large models the effort to re-model may not be practical.  In these cases
I suggest investigating conversion of certain key sections for performance.

<p>
Lee

<p>
<hr>
<hr>
Received: from wolf.arl.mil by CAD.ARL.MIL id aa02432; 8 Jun 98 16:03 EDT
Date:     Mon, 8 Jun 98 16:02:58 EDT
From:     Paul Tanenbaum &lt;pjt@arl.mil&gt;
To:       cmoore@arl.mil
cc:       acst@arl.mil
Subject:  Re: cell-fb use of -k at same time as -d
Message-ID:  &lt;9806081602.aa08851@wolf.arl.mil&gt;

<p>

<p>
Carl,
     You wrote...

<p>
&gt; If I use -k argument and ALSO use -d "0. 3" argument, the color key
&gt; comes out the same LENGTH as above, with the white (zero) value in
&gt; the same place (far left) as before.  *But* the right end of the color
&gt; key becomes a blue shade (apparently the equivalent of 0.3333333 value),
&gt; and in-between parts of the color key are interpolated between this
&gt; value and the left endpoint's zero.

<p>
&gt; The intent of the normalization is to get data into the "0 to 1" range,
&gt; so I would expect the color key to show the 0 to 1 range.  Why is the
&gt; color key altered when I do said normalization?

<p>
     The color key is altered because of a bug.  Your hunch about the
program's behavior was correct, and I've fixed it in the developmental
sources.  By the way, in tracking your bug, I discovered another one, too,
which I've also fixed.

<p>
     And I've implemented a new option, '-M r1 g1 b1 r2 g2 b2', which
specifies that the color scale should be--instead of the standard
blue-to-red w/ 0=white--interpolated between r1/g1/b1 and r2/g2/b2.  With
the -M option it's now easier to be less wasteful of the colors at one's
disposal.  For instance, ramping the cell data, say, from white to red
leaves all the other colors (greens, blues, yellows, etc.) available to
encode additional information in the image (e.g., text, aimpoints, delivery
accuracy, etc.)

<p>
     Thanks for your bug report,
     Paul

<p>
<hr>
<hr>
Received: from cad.arl.mil by CAD.ARL.MIL id aa24639; 22 Jun 98 16:23 EDT
Date: Mon, 22 Jun 1998 16:23:22 -0400 (EDT)
From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" &lt;jra@arl.mil&gt;
To: acst@arl.mil
Subject: Changes to db_comb.c and db_tree.c
Message-ID: &lt;Pine.SGI.3.95.980622161255.24383A-100000@cad.arl.mil&gt;
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

<p>

<p>
	Mike asked me to notify when I changed the combination
import/export routines. I have done that. They now convert the shader
info to/from the TCL format. I also modified db_apply_state_from_comb()
to convert from TCL format back to the "keyword=value" format, so that
rt will still work. Note that when you supply shader info to the "mater"
command in MGED, it must now be in TCL format. The format is a list
where the first member is the shader name and the second member is a
list of (white space separated) shader keywords/values. For example,

<p>
	plastic sh=5
is now:
	plastic {sh 5},
and,
	stack camo c3="255 255 255";plastic
is now:
	stack { {camo {c3 {255 255 255}}} {plastic {}}}

<p>
each member of the stack shaders parameter list is a shader list itself.

<p>

<p>
			-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058

<p>
AMC says that my views do not represent an official Government position.

<p>
<hr>
<hr>
Received: from walrus.arl.mil by CAD.ARL.MIL id aa07886; 7 Jul 98 9:18 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa15562; 7 Jul 98 8:39 EDT
Received: from cad.arl.mil by WALRUS.ARL.MIL id aa15528; 7 Jul 98 8:31 EDT
Received: from cad.arl.mil by CAD.ARL.MIL id aa07463; 7 Jul 98 8:27 EDT
Date: Tue, 7 Jul 1998 08:27:41 -0400 (EDT)
From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" &lt;jra@ARL.MIL&gt;
To: Marcel RICARD &lt;ricard@igr.fr&gt;
cc: cad@ARL.MIL
Subject: Re: Use rt command
In-Reply-To: &lt;3.0.1.32.19980706184830.00958dc0@igr.fr&gt;
Message-ID: &lt;Pine.SGI.3.95.980707082339.7446B-100000@cad.arl.mil&gt;
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

<p>
On Mon, 6 Jul 1998, Marcel RICARD wrote:

<p>
&gt; Dear BRL-CAD users,
&gt;
&gt; We are just trying to use the BRL-CAD package in the field of Medical
&gt; Physics concerning internal dosimetry. We use a SUN SPARCKstation 20 under
&gt; Solaris 2.4 and the software seems to be well installed on our computer. We
&gt; are able to build and edit objets but the rt command (do raytrace of view)
&gt; doesn't work. As we didn't find any information to view the result of rt
&gt; command, we want to know if anybody knows how to fix this problem.
&gt;
&gt; Thank you very much in advance for your help.
&gt;
&gt; Best regards,
&gt;
&gt; Marcel.

<p>
	The "rt" code will try to send its output to a framebuffer, so
you may need to tell it which framebuffer to use. You can use the "-F"
option or set the "FB_FILE" environment variable. A pretty safe choice
for framebuffer on a SUN is "/dev/Xl". Try the "fbhelp" command to see
the available framebuffers.

<p>
		-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058

<p>
AMC says that my views do not represent an official Government position.

<p>
<hr>
<hr>
Received: from walrus.arl.mil by CAD.ARL.MIL id aa14702; 7 Jul 98 11:28 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa17085; 7 Jul 98 11:20 EDT
Received: from admii.arl.mil by WALRUS.ARL.MIL id aa17081; 7 Jul 98 11:18 EDT
Received: from gsi-1.geosol.com by ADMII.ARL.MIL id aa03712; 7 Jul 98 10:54 EDT
Received: from localhost by gsi-1.GeoSol.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO)
	 id KAA16094; Tue, 7 Jul 1998 10:54:38 -0400
Date: Tue, 7 Jul 1998 10:54:35 -0400 (EDT)
From: "Harry J. Reed" &lt;reed@geosol.com&gt;
To: "John R. Anderson (USARL/SLAD/BVLD/VMB)" &lt;jra@ARL.MIL&gt;
cc: Marcel RICARD &lt;ricard@igr.fr&gt;, cad@ARL.MIL
Subject: Re: Use rt command
In-Reply-To: &lt;Pine.SGI.3.95.980707082339.7446B-100000@cad.arl.mil&gt;
Message-ID: &lt;Pine.SGI.3.96.980707103958.15957A-100000@gsi-1.GeoSol.com&gt;
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

<p>
&gt; On Mon, 6 Jul 1998, Marcel RICARD wrote:
&gt;
&gt; &gt; Solaris 2.4 and the software seems to be well installed on our computer. We
&gt; &gt; are able to build and edit objets but the rt command (do raytrace of view)
&gt; &gt; doesn't work. As we didn't find any information to view the result of rt
&gt; &gt; command, we want to know if anybody knows how to fix this problem.

<p>
Marcel,

<p>
  Sometimes our students have trouble getting RT to work and the cause of
this problem is usually easy to correct.

<p>
First:  Make sure that "/usr/brlcad/bin" is in your PATH.  The PATH is a
UNIX environment variable that tells what directories are to be searched
to find commands.  Even though you are in MGED, the RT command invokes an
outside code known as RT.  If your PATH is not set up correctly, then RT
is not found and therefore does not run.

<p>
        To determine whether this is your problem, try running RT outside
of MGED.  If the RT command is not found when it is run outside of MGED,
then it also will not be found if invoked inside of MGED.

<p>
SECOND:  As John pointed out, perhaps your frame buffer variables are not
set up correctly.  I do not suspect this in your case since the MGED
screen appears correctly.

<p>
        To determine whether this is the case, try invoking RT INSIDE MGED
with "rt -o junk.pix -s 512".  This will attempt, if everything else is
working correctly, a file named "junk.pix" in your current directory that
contains the image of whatever was on the MGED editor screen.  If the file
was created correctly and is somewhere around .75 MB in size, then your
problem is with the frame buffer.  Otherwise, perhaps the FIRST problem or
some other RT compilation problem may have occurred.

<p>
Hope this helps, Viva La France!

<p>
Harry Reed
Geometric Solutions, INC
+1 410 273 7058
Office Hours: Monday - Thursday 0930-1530, U.S. Eastern Standard Time

<p>

<p>
<hr>
<hr>
Received: from walrus.arl.mil by CAD.ARL.MIL id aa04086; 28 Aug 98 18:01 EDT
Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa24793; 28 Aug 98 17:31 EDT
Received: from admii.arl.mil by WALRUS.ARL.MIL id aa24787; 28 Aug 98 17:23 EDT
Received: from postal.clark.net by ADMII.ARL.MIL id aa29687; 28 Aug 98 17:09 EDT
Received: from loas.clark.net (loas.clark.net [168.143.0.13])
	by postal.clark.net (8.9.1/8.9.1) with ESMTP id RAA01691;
	Fri, 28 Aug 1998 17:10:17 -0400 (EDT)
Received: from shell.clark.net (klaatu@clark.net [168.143.0.8])
	by loas.clark.net (8.8.8/8.8.8) with SMTP id RAA17160;
	Fri, 28 Aug 1998 17:10:12 -0400 (EDT)
Date: Fri, 28 Aug 1998 17:09:05 -0400 (EDT)
From: klaatu &lt;klaatu@clark.net&gt;
To: "Karen A. Swartz" &lt;swartzk@email.uah.edu&gt;
cc: cad@ARL.MIL
Subject: Re: Linux
In-Reply-To: &lt;Pine.GSO.4.02.9808281613510.25607-100000@shell.clark.net&gt;
Message-ID: &lt;Pine.GSO.4.02.9808281705550.25607-100000@shell.clark.net&gt;
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

<p>

<p>
Correction, if you're running 8-bit X, you might want to do this under
'bash' which is probably your default Linux shell (otherwise use 'setenv'
instead of 'export'

<p>
export FB_FILE="/dev/XsPl"

<p>
You might or might not want to use the 's' option depending on how much
memory you've got.

<p>

<p>
On Fri, 28 Aug 1998, klaatu wrote:

<p>
&gt; On Fri, 28 Aug 1998, Karen A. Swartz wrote:
&gt;
&gt; &gt; I installed BRL-CAD and I worked through the tutorials for Mged.  However,
&gt; &gt; when I got to the ray tracing it didn't work like the tutorials said.  In
&gt; &gt; fact nothing really happened at all with the display.  Is there any major
&gt; &gt; differences when running in linux or Xwindows?  Is there some way of
&gt; &gt; checking if everything was installed correctly?
&gt;
&gt; Um, lessee - if I recall correctly, this is probably because you haven't
&gt; got your FB-FILE environment variable set right. There's more to it than
&gt; this, but I know that it must be set.
&gt;
&gt; In my /etc/profile (possibly you'd rather have this in your own 'bash'
&gt; ~/.profile file) add a line
&gt;
&gt; export FB_FILE="/dev/XsTl"
&gt;
&gt; Definitely read your 'man libfb' and related files, probably you've got a
&gt; different device from the XsTl device. But this works for me in 8-bit
&gt; SVGA under X.
&gt;
&gt;
&gt;
&gt; &gt;
&gt; &gt; Any input would be great.
&gt; &gt; I appreciate all your help.
&gt; &gt;
&gt; &gt;
&gt; &gt; Karen Swartz
&gt; &gt; Teledyne Brown Engineering
&gt; &gt; swartzk@email.uah.edu
&gt; &gt;
&gt; &gt;
&gt; &gt;
&gt;
&gt;
&gt;
&gt; Be kind to your neighbors, | "When the going gets weird the weird turn pro."
&gt; even though they be        | http://www.clark.net/pub/klaatu/home.html
&gt; transgenic chimerae.       | Now. Chock full of uninteresting links.
&gt; --------- Whom thou'st vex'd waxeth wroth ----------------
&gt; Re-transmission of this e-mail is a violation of Federal Copyright Law and
&gt;   subject to a per-instance violation damages charge of $250,000.00
&gt;

<p>

<p>

<p>
Be kind to your neighbors, | "When the going gets weird the weird turn pro."
even though they be        | http://www.clark.net/pub/klaatu/home.html
transgenic chimerae.       | Now. Chock full of uninteresting links.
--------- Whom thou'st vex'd waxeth wroth ----------------
Re-transmission of this e-mail is a violation of Federal Copyright Law and
  subject to a per-instance violation damages charge of $250,000.00

<p>
<hr>
<hr>
Date:     Fri, 28 Aug 98 23:13:44 EDT
From:     Mike Muuss  &lt;mike@arl.mil&gt;
To:       BND@ARL.MIL
cc:       Jcst@ARL.MIL, CAD@ARL.MIL
Subject:  BRL-CAD Support for PNG
Message-ID:  &lt;9808282313.aa09058@CAD.ARL.MIL&gt;

<p>

<p>
Of all the image file formats supported by Microsoft PowerPoint(tm),
Adobe PhotoShop (tm), Web browsers, and BRL-CAD(tm), the new PNG format
(Portable Network Graphics) is the best choice for the two-way exchange
of images.

<p>
PNG offers a typical compression ratio of 10:1, and uses a lossless
algorithm, so that there is no degradation of quality in the
decompressed image.

<p>
As you probably know, Jill has directed that all developmental BRL-CAD
and MUVES software is to be carefully protected. With Jill's express
permission, executable copies of these new PNG tools from the
developmental ("5.0") version of BRL-CAD have been added to the
"Production" BRL-CAD 4.4 executable tree stored in /usr/brlcad/ on the
IRIX 5.3 (wilson.arl.mil) and IRIX 6 (raven.arl.mil) RDIST master
machines. These binaries will be available to every machine that
subscribes to the ARL rdist service, including machines at ARDEC, TECOM,
CECOM, and elsewhere.

<p>
The programs png-fb, fb-png, and any-png.sh have been added, and the
programs pixinfo.sh and show.sh have been upgraded to support PNG.
Manual pages for png-fb and fb-png have also been installed. These files
should go out on the Friday night RDIST.

<p>
The any-png.sh script is a convenient tool which can convert one image
in any of our common formats (pix, bw, rle, yuv, jpeg, and gif) into
PNG. To convert an entire directory of images into PNG format, just run:

<p>
	for i in *
	do
		any-png.sh $i
	done

<p>
The PNG files are written in the current directory even if the input
file is taken from another directory.  So to get your own PNG version of
the radar teapot, you can just run:

<p>
	any-png.sh /n/wolf/demo/rt/radar-teapot.rle

<p>
You can then view the resulting image by running either:

<p>
	png-fb radar-teapot.png
or
	show.sh radar-teapot.png

<p>
(The show.sh program can display most image formats on your BRL-CAD
framebuffer.)

<p>
This is a great way to zap your V/L analysis results painlessly into
PowerPoint or PhotoShop!

<p>
Credit:  As an interesting historical note, the PNG format was developed
by a large group of people, including Glenn Randers-Pehrson, a long-time
Army employee (ARDEC, BRL-TBD, ARL-WMRD), now retired.  John Anderson
ported the PNG library into the BRL-CAD source tree, and he and I wrote
these new converter tools.

<p>
	Enjoy!
	 -Mike
<hr>
<hr>
Date:     Wed, 30 Dec 1998 22:29:38 EST
From:     Mike Muuss  &lt;mike@arl.mil&gt;
To:       Lamas@ARL.MIL
cc:       Morrison@ARL.MIL
Subject:  brlcad-check.sh split out from setup.sh
Message-ID:  &lt;199812302229.aa22878@CAD.ARL.MIL&gt;

<p>

<p>
As an additional tool for us developers, I've broken out the parts
of setup.sh that checked the settings of $PATH, cake, machinetype.sh
and Cakefile.defs into a separate shell script named "brlcad-check.sh".

<p>
setup.sh runs brlcad-check.sh, but if you're unsure about whether
your path is set right, you can run it directly.

<p>
Best of all, if you're struggling to get machinetype.sh and cake and
Cakefile.defs to all agree, you don't have to re-run setup.sh (and
be forced to recompile CAKE) each time you experiment.

<p>
	Best,
	 -Mike

<p>
<hr>
<hr>
Date:     Thu, 31 Dec 1998 01:24:41 EST
From:     Mike Muuss  &lt;mike@arl.mil&gt;
To:       Lamas@ARL.MIL
cc:       Jill@ARL.MIL, Wendy@ARL.MIL
Subject:  Release 5.0 on FreeBSD
Message-ID:  &lt;199812310124.aa09935@CAD.ARL.MIL&gt;

<p>

<p>
As a starting point today, I modified gen.sh and Cakefile.defs
to support using the vendor-provided versions of the TCL and Tk
libraries, when compatible versions are provided.  In the case of
both FreeBSD and Linux, libtcl8.0 and libtk8.0 are available.
In those cases, one less thing we need to ship along.

<p>
This evening I succeeded in taking the final step in the FreeBSD port:
getting the package to build using shared libraries and optimization.
Now that I've figured out all the magical compiler options needed,
it works just fine!  The full install tree for FreeBSD is 13.7 Mbytes,
just slightly larger than a full install for Linux (12.7 Mbytes).

<p>
This is an extremely small disk requirement for modern software; the
full BRL-CAD package can fit nicely on any laptop computer running
FreeBSD or Linux.

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from cad.arl.mil by CAD.ARL.MIL id aa24829; 25 Jan 1999 09:32 EST
Date: Mon, 25 Jan 1999 09:32:45 -0500 (EST)
From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" &lt;jra@arl.mil&gt;
To: acst@arl.mil
Subject: "db adjust" command
Message-ID: &lt;Pine.SGI.3.95.990125092928.7787A-100000@cad.arl.mil&gt;
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

<p>

<p>
	I have modified db_tcl_comb_adjust() in tcl.c such that a "db
adjust any_comb_parameter none" will set that parameter to its "not used",
or its default value.

<p>
		-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058

<p>
AMC says that my views do not represent an official Government position.

<p>
<hr>
<hr>
Date:     Mon, 25 Jan 1999 13:38:18 EST
From:     "Lee A. Butler" &lt;butler@arl.mil&gt;
To:       acst@ARL.MIL
Subject:  New "stack" type shader
X-URL:    http://ftp.arl.mil/~butler/index.html
Message-ID:  &lt;199901251338.aa00538@CAD.ARL.MIL&gt;

<p>

<p>
A new shader called "extern" was born in about 40 lines of code today.  It's
just a version of the venerable "stack" shader that takes it's parameters
from an external file.  The only parameter is the name of the file containing
the real parameters.  Usage:

<p>
	mged&gt; mater foo.r "extern {shader.txt}" 255 255 255 1

<p>
Then you need to fill in the file "shader.txt" with the actual parameters
you wanted on the command line.

<p>
	mged&gt; exec cat shader.txt
	camo s=200 t1=-.3 t2=.125;plastic di=.8

<p>
This lame little hack allows us to sneak around the buffer length limits in
the v4 database format.

<p>
Lee
<hr>
<hr>
Received: from cad.arl.mil by CAD.ARL.MIL id aa05575; 17 Mar 1999 14:53 EST
Received: from cad.arl.mil by CAD.ARL.MIL id aa04464; 17 Mar 1999 14:49 EST
Date: Wed, 17 Mar 1999 14:49:55 -0500 (EST)
From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" &lt;jra@arl.mil&gt;
To: Tom Browder &lt;tom2@fwb.asi.srs.com&gt;
cc: cad@ARL.MIL
Subject: Re: mged's Maximum Tree Depth
In-Reply-To: &lt;01be6ca9$51eb4ac0$cb01000a@tomtom2.asi-fwb.com&gt;
Message-ID: &lt;Pine.SGI.3.95.990317144712.5803A-100000@cad.arl.mil&gt;
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

<p>
On Fri, 12 Mar 1999, Tom Browder wrote:

<p>
&gt; The stock mged has a useful tree depth of twelve levels.  Is there a simple
&gt; constant change in the source code to increase that or is it more than a
&gt; trivial change?
&gt;
&gt; Thanks.
&gt;
&gt; Tom Browder
&gt;
&gt;
&gt;

<p>
	Yes, in "h/solid.h", there is a line that defines MAX_PATH. You
can adjust this, then recompile mged. Making this larger will increase
the memory used for each solid in MGED's display.

<p>

<p>
		-John

<p>
John R. Anderson
Attn: AMSRL-SL-BV                               Internet: jra@arl.mil
U.S. Army Research Laboratory                   Phone: (410) 278-7267
Aberdeen Proving Ground, MD  21005-5068         FAX: (410) 278-5058

<p>
AMC says that my views do not represent an official Government position.

<p>
<hr>
<hr>
<a href="mailto:mike@arl.mil">
  &lt;<em> mike@arl.mil </em>&gt;
  </a>

<br>
<a href="index.html"> Release notes for other versions of BRL-CAD </a>
</body>
